Re: ssh + compiled-in SKEY support considered harmful?
shouldn't the default be no skey? On Mon, Apr 22, 2002 at 09:41:20PM -0400, Anthony Schneider wrote: > On Mon, Apr 22, 2002 at 08:04:43PM -0500, Mike Meyer wrote: > > In <[EMAIL PROTECTED]>, Jordan Hubbard ><[EMAIL PROTECTED]> typed: > > > My question: Who's "wrong" here, FreeBSD or Mac OS X? If the latter, > > > > Someone decided that FreeBSD should do challengeresponse > > authentication by default. You can fix it by uncommenting the line > > "#ChallengeResponseAuthentication no" in /etc/ssh/sshd_config. > > > > that's what fixxed it for me, too. > SkeyAuthentication no also does it. :) > -Anthony. > > --- > PGP key at: > http://www.keyserver.net/ > http://www.anthonydotcom.com/gpgkey/key.txt > Home: > http://www.anthonydotcom.com > --- > -- pgp fingerprint: BC64 2E7A CAEF 39E1 9544 80CA F7D5 784D FB46 16C1 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: secure Filesystem
On Thu, Aug 16, 2001 at 12:48:59PM -0700, Darryl Okahata wrote: > A bigger problem is that doing anything with a file uses up 1-2KB > PER FILE. If you want to see cfsd grow *really big*, do a "find ." of > any large cfs-controlled hierarchy with lots of files. I'd really like > to put my MH mail messages under cfs, but I've got too many files (I > can't afford having a 200+MB cfsd). I don't seem to have that problem... voyager ~ > du -sk crypt 1342056 crypt voyager ~ > find /crypt/obonilla >& /dev/null voyager ~ > du -sk crypt 1342056 crypt am i missing something? should i just be happy ;) regards, -oscar -- pgp fingerprint: BC64 2E7A CAEF 39E1 9544 80CA F7D5 784D FB46 16C1 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
PF_LOCAL in getaddrinfo
I was trying to compile OpenLDAP 2 with support for ldapi:///
which uses the PF_LOCAL family. However, I've discovered that
the PF_LOCAL entry in getaddrinfo is ifdef'd out.
This is the relevant code for /usr/src/lib/libc/net/getaddrinfo.c
#if 0
{ PF_LOCAL, 0, ANY, ANY, NULL, 0x01 },
#endif
Is this an error in the way OpenLDAP uses getaddrinfo or is there
a reason for not supporting AF_LOCAL in calls to getaddrinfo?
Thanks,
-Oscar
--
pgp public key: finger [EMAIL PROTECTED]
pgp fingerprint: 9735 2F52 D499 17E2 D03B 5960 241D 09EA 349F 923E
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
NSS for FreeBSD
[ long email --- there's a specific question at the end ] I've started work a couple of weeks ago to port the NSS implementation from NetBSD to FreeBSD. This is needed for things like authenticating with an LDAP server, etc. If you search for LDAP in Hackers you'll find a thread that discusses why it's needed in more detail. I've put up a web page showing the status of the NSS port. It's at http://www.fisicc-ufm.edu/~obonilla/nss/ In brief: nsdispatch() has been incorporated to the FreeBSD libc code. getpwent(), getpwnam(), and getpwuid() all call nsdispatch() and work for both files and nis. I wish I could say that work in this file is completed, but I still haven't got to the compat implementation. See below. There are a bunch of other files that need to be modified to make use of the new nsdispatch function. There's a list at the URL given above. I need help with the NIS code. In particular I wish someone could explain to me exactly what the unwind() function in getpwent() does. In detail: The nsdispatch() function is *exactly* the same as in NetBSD. Thus, the NSS mechanism currently works on FreeBSD exactly as it workd in NetBSD. NetBSD's way: Basically you have a file named /etc/nsswitch.conf which tells the C library where to get the info from. So if you have a line saying: hosts files nis it means that /etc/hosts is checked first and the yp maps are checked next. The man page explains this in more detail and is available in the URL given above for those who don't have NetBSD. NetBSD provides also a compatibility mode for two of the system's databases (passwd and group). For example: passwd compat means that the system will behave as it did before the nsdispatch function was added. e.d. lookup files first and if it finds a line +:: then it will lookup nis. NetBSD provides an extra parameter, namely: passwd_compatnis which tells the system which database to use *after* files and when it finds the +: token. This makes sense since NetBSD supports two different databases besides files out of the box: NIS, and Hesiod (extra DNS records). I personally don't see this as a big benefit, since if I wanted to have the system lookup stuff first in files and then in, say, hesiod. I would just get rid of the + token in /etc/passwd and change the /etc/nsswitch.conf to be: passwd files dns instead of relaying on the compat stuff. I'm sure there's a good reason they did it like this, I just can't seem to find it. FreeBSD's proposed way: Given that FreeBSD doesn't support Hesiod, I think it would make sense to have nsswitch behave the following way: *exactly* like NetBSD for all databases minus compat. *only* for compat: get rid of the foo_compat blah to select blah as the source for database foo and simply make compat mode behave exactly as it behaves now (pre nss); which is, lookup files and if it finds the +: token, lookup NIS. Specific Question: For the FreeBSD implementation of NSS: is it worth to have a way to tell the compat database which source to use for the +: token in /etc/passwd or should it just default to NIS? Help: If someone is interested in helping with this I would appreciate it. Thanks and Regards, -Oscar -- pgp public key: finger [EMAIL PROTECTED] pgp fingerprint: 6D 18 8C 90 4C DF F0 4B DF 35 1F 69 A1 33 C7 BC To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: LDAP NIS replacement
On Tue, Mar 14, 2000 at 04:23:32PM -0800, yramin wrote: > Hi, > > New to the list, but I'm looking into developing a way to > authenticate and grab user information from an LDAP server compared > to /etc/passwd and company, or NIS. I was poking around the library > code and noticed that FreeBSD does not have NSS (name service > switch) support (otherwise I would use nss_ldap already out there - > it doesn't compile under FreeBSD even with IRS use enabled, I've > tried ). What would be the best way to write new getpwent(), > etc. routines for FreeBSD? I could stick them into a library and > have programs that want to use them link to it, but that is a pain > (although quite portable :)). > I'm working on a PAM system first (yes, pam_ldap is out there, but > it sucks, lots of linuxisms), but would be interested getting some > work done on this as well. Any thoughts, advice, pointers? PLEASE use the enter key about every 80 characters... your email looks horrible ;) I'm working precisely on this. I've integrated the NSS functionality from NetBSD into the standard C library of FreeBSD. I'm in the process of rewriting the get* function to use the dispatcher. Once we have that, the way to go would be to have the C library dlopen the required modules as PAM does. Are you sure that nss_ldap doesn't compile on freebsd? I think I compiled it once (and of course it was unusable since FreeBSD lacks NSS). regards, -oscar -- pgp public key: finger [EMAIL PROTECTED] pgp fingerprint: 6D 18 8C 90 4C DF F0 4B DF 35 1F 69 A1 33 C7 BC To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: inner workings of the C compiler
On Sat, Mar 11, 2000 at 02:30:19PM +0100, Marco van de Voort wrote:
> P.s. Could you sent me a minimal C program linking to libc, and the
> commandline to compile it with -nostdlib ?
>
> I could throw all these experiences with non standard linking in a
> little tex doc. ( --nostdlib with and without libc, pure assembler
> instead of c (no gcc), some small chapter about syscall conventions
> etc)
Here's what I have for a test program:
-
#include
#include
#include
int main () {
struct passwd *password;
while ( (password = getpwent()) != NULL ) {
printf("login: %s\n", password->pw_name);
}
password = getpwnam("root");
printf("root has uid: %d\n", password->pw_uid);
password = getpwuid(0);
printf("uid 0 is %s\n", password->pw_name);
return 0;
}
-
I copied /usr/src/lib/libc and /usr/src/lib/csu to the parent dir of
this test, and thus my makefile is:
-
all: get-test
get-test.o: get-test.c
cc -g -Wall -pedantic -ansi -c -I../libc/include get-test.c
get-test: get-test.o
cc -g -nostdlib -static -L../libc -o get-test \
../csu/i386-elf/crt1.o \
../csu/i386-elf/crti.o \
../csu/i386-elf/crtbegin.o \
get-test.o \
../csu/i386-elf/crtend.o \
../csu/i386-elf/crtn.o \
-lc
clean:
rm -f nss-test get-test *.o *.core *.*~
-
The ordering above was pointed to me by Chuck Robey who got it using
the -v flag to cc (which shows you what the C compiler is doing to get
good links).
I'm not 100% sure that the -lc should be at the end... more likely it
should be right after (before?) my object file (get-test.o), but it
seems to work both ways.
regards,
-oscar
--
pgp public key: finger [EMAIL PROTECTED]
pgp fingerprint: 6D 18 8C 90 4C DF F0 4B DF 35 1F 69 A1 33 C7 BC
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: inner workings of the C compiler
On Fri, Mar 10, 2000 at 07:49:32PM -0500, Chuck Robey wrote: > Notice here the order it links, and what files it links in. First, if > you're using nostdlib, then you have to call out your own libs, all of > them, and you forgot to do libgcc. I've been able to move the lib calls I don't really need libgcc since I'm only calling funtions in libc, but... > before and after the object files, so I don't think that order matters, as > long as you get both, but the objects (in order) are: > > crt1.o crti.o crtbegin.o ccn35733.o (your obj, that is) , then > crtend.o crtn.o > > It calls out the ld-elf.so.1, but I don't think that's really linked > in. I've been doing all my stuff statically linked, so I could be wrong > on that part of it. I don't think you need to care about the -L calls, > because when you use the full path, -L doesn't really matter. > > Always remember that -v, when your messing with tools. > That ordering completly solved it!! thanks... now I can get back to getting the NSS code into libc. kind regards and many thanks, -oscar -- pgp public key: finger [EMAIL PROTECTED] pgp fingerprint: 6D 18 8C 90 4C DF F0 4B DF 35 1F 69 A1 33 C7 BC To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: inner workings of the C compiler
On Sat, Mar 11, 2000 at 12:58:13AM +0100, Marco van de Voort wrote: > > > to try things out i create a static binary and coerce it to use my > > C library instead of the system's one. > > > > this is how i compile my program: > > > > cc -g -DYP -DFreeBSD -Wall -pedantic -ansi -c -I../../libc/include nss-test.c > > cc -g -nostdlib -static -L../../libc -o nss-test nss-test.o \ > > ../../csu/i386-elf/crt1.o ../../csu/i386-elf/crti.o -lc > > I'm no expert, but I tried something like this a few weeks back(to totally link >without > libc), and I was wondering, aren't you missing crtbegin and crtend ? > YES! that took care of the double calling of the first function of the first file... I still get the bus error at the end of my program in the atexit() call. this is because _fini is invalid. do you know the exact order in which I should link the objects? regards, -oscar -- pgp public key: finger [EMAIL PROTECTED] pgp fingerprint: 6D 18 8C 90 4C DF F0 4B DF 35 1F 69 A1 33 C7 BC To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: inner workings of the C compiler
On Fri, Mar 10, 2000 at 04:35:18PM -0800, Alfred Perlstein wrote: > It seems to be working just fine, I suspect that there's something wrong > with your code and you're referencing a function that somehow is not > being compiled into libc: > > ~ % nm /usr/lib/libc.a | grep nsdispatch > ~ % > > is this a function you've added? Are you _sure_ it's being > compiled into the libc you're making? yes, it *is* being compiled into my C library. If I compile a static binary it works (aside from the bus error at the end and the double calling of the first funtion of the first object file listed). regards, -oscar -- pgp public key: finger [EMAIL PROTECTED] pgp fingerprint: 6D 18 8C 90 4C DF F0 4B DF 35 1F 69 A1 33 C7 BC To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: inner workings of the C compiler
On Fri, Mar 10, 2000 at 06:51:20PM -0500, Chuck Robey wrote:
> I wasn't reading this too closely, but if you're trying to hand feed in
> the object files, the C startup object file *MUST* come first in the list
> of object files, because it's gotta link at the lowest address ...
>
> Is that it?
Ok, I'm even more puzzled than before...
If I link them in this order: nss-test.o crt1.o crti.o
I get the following:
files called
files called
retval = 1
NS_SUCCESS
Bus error (core dumped)
Notice the duplicate line that says "files called"? This had me puzzled
before, but now I see that somehow _init point to the first function
in the first object file
(gdb) p _init
$1 = {} 0x8048074
Now if I like it in this order: crt1.o crti.o nss-test.o
I get an infinite recursion
(gdb) p _init
$1 = {} 0x8048074 <_start>
since _start calls _init() *before* calling main() it just loops
(and starts swapping like hell)
Let me try this order: crti.o crt1.o nss-test.o
(gdb) p _init
$1 = {} 0x8048074 <_start>
nope, same as before. infinite recursion and swapping like hell.
maybe this order: crt1.o nss-test.o crti.o
(gdb) print _init
$1 = {} 0x8048074 <_start>
same thing.
I created a small C file:
#include
foo() {
printf("foo\n");
}
and tried this order: foo.o nss-test.o crt1.o crti.o
(gdb) print _init
$1 = {} 0x8048074
and if I just run it...
foo
files called
retval = 1
NS_SUCCESS
Bus error (core dumped)
If I try gdb with a normal program (i.e. one linked with the standard
C library in /usr/lib and not my own C library)
(gdb) print _init
$1 = {} 0x804838c <_init>
What could be the problem?
regards,
-oscar
--
pgp public key: finger [EMAIL PROTECTED]
pgp fingerprint: 6D 18 8C 90 4C DF F0 4B DF 35 1F 69 A1 33 C7 BC
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: inner workings of the C compiler
On Fri, Mar 10, 2000 at 03:27:37PM -0800, Alfred Perlstein wrote: > I think you'll want LD_LIBRARY_PATH to be: > /home/obonilla/freebsd/nss/libc/:/usr/lib:/usr/local/lib I don't see why since the only library I use is libc. Anyway, I tried just for kicks and still got the same error. $ echo $LD_LIBRARY_PATH /home/obonilla/freebsd/nss/libc:/usr/lib:/usr/local/lib $ echo $LD_PRELOAD /home/obonilla/freebsd/nss/libc/libc.so.4 $ make cc -g -DYP -DFreeBSD -Wall -pedantic -ansi -o nss-test -I../../libc/include nss-test.c /tmp/ccE93722.o: In function `main': /home/obonilla/freebsd/nss/tests/libc/nss-test.c(.text+0xb0): undefined reference to `nsdispatch' *** Error code 1 Stop in /usr/home/obonilla/freebsd/nss/tests/libc. > please use the dynamic, it's a hell of a lot easier. sure, as soon as it works I'll use it ;) > probably, but without a traceback it's going to be hard to find > out exactly what. > $ cp Makefile.static Makefile $ make cc -g -DYP -DFreeBSD -Wall -pedantic -ansi -c -I../../libc/include nss-test.c cc -g -nostdlib -static -L../../libc -o nss-test nss-test.o ../../csu/i386-elf/crt1.o ../../csu/i386-elf/crti.o -lc $ ./nss-test files called files called retval = 1 NS_SUCCESS Bus error (core dumped) $ gdb nss-test nss-test.core GNU gdb 4.18 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-unknown-freebsd"... Core was generated by `nss-test'. Program terminated with signal 10, Bus error. #0 0x80528e4 in ?? () (gdb) where #0 0x80528e4 in ?? () #1 0x80481ff in _start () at crt1.c:95 (gdb) as I said in the first mail, this has to do with crt1.c calling atexit() with a valid address (0x80528e4) and somehow the argument to atexit() getting to be NULL once inside atexit()... I'd really like to use the dynamic stuff but I can't seem to make it compile. > Of course we are, please file a PR when you think it's pretty much > completed or email -hackers if you need/want advice. :) Ok, I'll start firing questions about NIS at -hackers regards, -oscar -- pgp public key: finger [EMAIL PROTECTED] pgp fingerprint: 6D 18 8C 90 4C DF F0 4B DF 35 1F 69 A1 33 C7 BC To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: inner workings of the C compiler
On Thu, Mar 09, 2000 at 05:20:31PM -0800, Kris Kennaway wrote: > On Wed, 8 Mar 2000, Alfred Perlstein wrote: > > > I'm pretty sure this can be done a hell of a lot easier by using shared > > libraries and using the enviornment variables LD_LIBRARY_PATH and > > LD_PRELOAD, see the rtld manpage for more help. > > Yes, I've done this when trying to track down buffer overflows in > libc..stick them in their own directory and use LD_LIBRARY_PATH, which > tells the dynamic linker where to search. > $ echo $LD_LIBRARY_PATH/ /home/obonilla/freebsd/nss/libc/ $ echo $LD_PRELOAD /home/obonilla/freebsd/nss/libc/libc.so.4 $ make cc -g -DYP -DFreeBSD -Wall -pedantic -ansi -o nss-test -I../../libc/include nss-test.c /tmp/ccy93427.o: In function `main': /home/obonilla/freebsd/nss/tests/libc/nss-test.c(.text+0xb0): undefined reference to `nsdispatch' *** Error code 1 Stop in /usr/home/obonilla/freebsd/nss/tests/libc. $ at this point I switch makefiles to use static building and... $ make cc -g -DYP -DFreeBSD -Wall -pedantic -ansi -c -I../../libc/include nss-test.c cc -g -nostdlib -static -L../../libc -o nss-test nss-test.o ../../csu/i386-elf/crt1.o ../../csu/i386-elf/crti.o -lc $ but when I run the binary... $ ./nss-test files called files called retval = 1 NS_SUCCESS Bus error (core dumped) $ am I doing something wrong? BTW... I've ported the Name Service Switch from NetBSD to FreeBSD and it's working on my laptop right now. However, I need some help moving all the get*by* functions in the C library to use the new nsdispatch function, especially for the NIS code... who should I talk to... anyone interested on seeing some patches? regards, -oscar -- pgp public key: finger [EMAIL PROTECTED] pgp fingerprint: 6D 18 8C 90 4C DF F0 4B DF 35 1F 69 A1 33 C7 BC To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
inner workings of the C compiler
i'm working on the C library, and to make debuggin easy i've copied
/usr/src/lib/libc to another directory and only build libc.a.
i've also copied /usr/src/lib/csu/i386-elf to another directory and
have enabled debug symbols on both csu and libc.
to try things out i create a static binary and coerce it to use my
C library instead of the system's one.
this is how i compile my program:
cc -g -DYP -DFreeBSD -Wall -pedantic -ansi -c -I../../libc/include nss-test.c
cc -g -nostdlib -static -L../../libc -o nss-test nss-test.o \
../../csu/i386-elf/crt1.o ../../csu/i386-elf/crti.o -lc
now, the program runs fine, but at the very end gives me a bus error
and core dumps... i've tracked the bug to the following call in line 90
csu/i386-elf/crt1.c in function _start()
atexit(_fini);
at this point, in gdb
(gdb) print _fini
$1 = {} 0x80528e4
(gdb) step
atexit (fn=0x80528e4)
at /usr/home/obonilla/freebsd/nss/libc/../libc/stdlib/atexit.c:59
1: __progname = 0xbfbffa86 "nss-test"
(gdb) print fn
$2 = (void (*)()) 0
fn is the argument to atexit()
later, in fuction exit() it will try to dereference a null pointer due
to the above...
i'm puzzled by this behavior... am i missing something?
how is it possible that the value i'm seeing before the call to atexit()
(0x80528e4) gets to be null once inside atexit()?
thanks and regards,
-oscar
--
pgp public key: finger [EMAIL PROTECTED]
pgp fingerprint: 6D 18 8C 90 4C DF F0 4B DF 35 1F 69 A1 33 C7 BC
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: more info Re: how did I manage this?
On Sun, Sep 12, 1999 at 12:29:55PM -0400, Wayne Cuddy wrote: > >rm '$DEST_DIR' > rm: $DEST_DIR: is a directory > > >ls '$DEST_DIR' > $2 > rm doesn't work on directories.. go for $ rm -rf '$DEST_DIR' or $ rm '$DEST_DIR'/'$2' $ rmdir '$DEST_DIR' regards, -Oscar -- For PGP Public Key: finger [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: more info Re: how did I manage this?
On Sun, Sep 12, 1999 at 12:29:55PM -0400, Wayne Cuddy wrote: > >rm '$DEST_DIR' > rm: $DEST_DIR: is a directory > > >ls '$DEST_DIR' > $2 > rm doesn't work on directories.. go for $ rm -rf '$DEST_DIR' or $ rm '$DEST_DIR'/'$2' $ rmdir '$DEST_DIR' regards, -Oscar -- For PGP Public Key: finger oboni...@fisicc-ufm.edu To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: UCB removes advertising clause
On Fri, Sep 03, 1999 at 11:32:24AM -0500, Chris Costello wrote: > On Fri, Sep 03, 1999, Oscar Bonilla wrote: > > does that mean we can get rid of the copyright of the University at > > boot time? do we want to? > >If it were up to me, we would not want to. I feel we should > continue to give UCB credit regardless of whether that particular > clause in the license agreement is enforced. Without them, where > would we be? > I totally agree here. Besides it shows a certaing linage to be a direct descendant of Berkeley Unix :) -Oscar -- For PGP Public Key: finger oboni...@fisicc-ufm.edu To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: UCB removes advertising clause
On Fri, Sep 03, 1999 at 11:32:24AM -0500, Chris Costello wrote: > On Fri, Sep 03, 1999, Oscar Bonilla wrote: > > does that mean we can get rid of the copyright of the University at > > boot time? do we want to? > >If it were up to me, we would not want to. I feel we should > continue to give UCB credit regardless of whether that particular > clause in the license agreement is enforced. Without them, where > would we be? > I totally agree here. Besides it shows a certaing linage to be a direct descendant of Berkeley Unix :) -Oscar -- For PGP Public Key: finger [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: UCB removes advertising clause
On Thu, Sep 02, 1999 at 12:23:38PM -0700, Brian W. Buchanan wrote: > This is apparently old news, but I don't recall seeing anything about it > on the lists, and didn't hear about it until it hit Slashdot a short while > ago. > > ftp://ftp.cs.berkeley.edu/pub/4bsd/README.Impt.License.Change: > > July 22, 1999 > Yeah, McKusick talked about this last usenix, he said he was trying to convince UCB of how useless this clause was... seems he made it :) does that mean we can get rid of the copyright of the University at boot time? do we want to? regards, -Oscar -- For PGP Public Key: finger oboni...@fisicc-ufm.edu To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: UCB removes advertising clause
On Thu, Sep 02, 1999 at 12:23:38PM -0700, Brian W. Buchanan wrote: > This is apparently old news, but I don't recall seeing anything about it > on the lists, and didn't hear about it until it hit Slashdot a short while > ago. > > ftp://ftp.cs.berkeley.edu/pub/4bsd/README.Impt.License.Change: > > July 22, 1999 > Yeah, McKusick talked about this last usenix, he said he was trying to convince UCB of how useless this clause was... seems he made it :) does that mean we can get rid of the copyright of the University at boot time? do we want to? regards, -Oscar -- For PGP Public Key: finger [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: NSS Project
On Fri, Aug 27, 1999 at 01:33:03PM -0500, John Sconiers wrote: > > I was looking for followups to this thread and have searched the archives > for more information without luck. I have a few questions. Has this > project furthered any and where can one get the diffs / source??? Is > there a website that goes in depth about the project. > > I've been very busy and seem to be the only one doing something along this line. As I said earlier, I've ported the nss stuff from NetBSD and posted some patches to the list a while back that had the nsdispatch function implemented. It was not a complete implementation since the get*ent functions in libc were not modified to use the nsdispatch function. I started to look into nsdispatch to make it dynamically load the get*ent functions using dlload (a la pam) but had a lot of work in the meantime and didn't finish the stuff. I've started looking into the code agan (yesterday) and it doesn't seem too difficult to have it dynamically load the stuff. I'll post to the list when I have code that actually does something :) regards, -Oscar -- For PGP Public Key: finger oboni...@fisicc-ufm.edu To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: NSS Project
On Fri, Aug 27, 1999 at 01:33:03PM -0500, John Sconiers wrote: > > I was looking for followups to this thread and have searched the archives > for more information without luck. I have a few questions. Has this > project furthered any and where can one get the diffs / source??? Is > there a website that goes in depth about the project. > > I've been very busy and seem to be the only one doing something along this line. As I said earlier, I've ported the nss stuff from NetBSD and posted some patches to the list a while back that had the nsdispatch function implemented. It was not a complete implementation since the get*ent functions in libc were not modified to use the nsdispatch function. I started to look into nsdispatch to make it dynamically load the get*ent functions using dlload (a la pam) but had a lot of work in the meantime and didn't finish the stuff. I've started looking into the code agan (yesterday) and it doesn't seem too difficult to have it dynamically load the stuff. I'll post to the list when I have code that actually does something :) regards, -Oscar -- For PGP Public Key: finger [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Serial cable
On Fri, Aug 20, 1999 at 03:12:48PM -0400, Zhihui Zhang wrote: > > Hi, Rich: > > Can you find a serial cable for me? I need to connect two PCs together > via RS232 ports. > Aha! Remote Kernel Debugging aren't we? Probably you did not intend this mail to go to the mailing list :) Regards, -Oscar -- For PGP Public Key: finger oboni...@fisicc-ufm.edu To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Serial cable
On Fri, Aug 20, 1999 at 03:12:48PM -0400, Zhihui Zhang wrote: > > Hi, Rich: > > Can you find a serial cable for me? I need to connect two PCs together > via RS232 ports. > Aha! Remote Kernel Debugging aren't we? Probably you did not intend this mail to go to the mailing list :) Regards, -Oscar -- For PGP Public Key: finger [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
NSS Project update
After collecting a bunch of emails from the list, this is the approach I'll be taking: 1. use the existing nsdispatch code obtained from NetBSD as a base for parsing the /etc/nsswitch.conf file. 2. Make the C library nsdispatch aware. The dtab[] array will be filled dynamicaly from the contents of /etc/nsswitch.conf. I'm still not sure if this has to be done "whithin" the C library or if nsdispatch should fill the dtab[] array itself and not relay on the caller (i.e. drop the dtab[] parameter). It seems to me at this point that the easiest approach is to have nsdispatch fill the dtab array itself. 3. Move the current implementation of the get*ent and get*by* from the C library to three dynamically loaded modules, namely: nss_files.so, nss_nis.so, and nss_dns.so 4. Add more nss_*.so modules for things like LDAP, etc. once again: comments, suggestions. Someone mentioned that we should still be able to produce statically linked binaries for things like /stand and /sbin. I suggest making the nsdispatch (or get* functions) revert to files if everything else fails (not the modules themselves, but the loading of the modules). How does this sound? Regards, -Oscar -- For PGP Public Key: finger oboni...@fisicc-ufm.edu To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
NSS Project update
After collecting a bunch of emails from the list, this is the approach I'll be taking: 1. use the existing nsdispatch code obtained from NetBSD as a base for parsing the /etc/nsswitch.conf file. 2. Make the C library nsdispatch aware. The dtab[] array will be filled dynamicaly from the contents of /etc/nsswitch.conf. I'm still not sure if this has to be done "whithin" the C library or if nsdispatch should fill the dtab[] array itself and not relay on the caller (i.e. drop the dtab[] parameter). It seems to me at this point that the easiest approach is to have nsdispatch fill the dtab array itself. 3. Move the current implementation of the get*ent and get*by* from the C library to three dynamically loaded modules, namely: nss_files.so, nss_nis.so, and nss_dns.so 4. Add more nss_*.so modules for things like LDAP, etc. once again: comments, suggestions. Someone mentioned that we should still be able to produce statically linked binaries for things like /stand and /sbin. I suggest making the nsdispatch (or get* functions) revert to files if everything else fails (not the modules themselves, but the loading of the modules). How does this sound? Regards, -Oscar -- For PGP Public Key: finger [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Berkeley IRS and NSS
Anyone knows about the BSD Information Retrieval Service (IRS) mentioned in http://www.padl.com/nss_ldap.html ? It seems to accomplish the same thing as the NSS stuff we've been talking about. Regards, -Oscar -- For PGP Public Key: finger oboni...@fisicc-ufm.edu To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Berkeley IRS and NSS
Anyone knows about the BSD Information Retrieval Service (IRS) mentioned in http://www.padl.com/nss_ldap.html ? It seems to accomplish the same thing as the NSS stuff we've been talking about. Regards, -Oscar -- For PGP Public Key: finger [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
NSS Project
Following on the NSS (Name Service Switch):
*Step One: I ported the NetBSD implementation of nsdispatch(3) as implemented
by Luke Mewburn. See attached patch to libc and new header file. I'm also
attaching the man page for /etc/nsswitch.conf. Right now it compiles,
installs, and works for some simple tests I've run.
*Step Two: make getpwent, getgrent, and friends actually use the nsdispatch
function. I've already started looking at the source, but am having trouble
with the NIS part. Maybe someone more knowledgeable could write the NIS
function.
Basically we have to reduce each of the functions to a simple nsdispatch
call and then implement the real functions... Here's an example from
getpwent.c
/* Basically we reduce getpwent to a simple nsdispatch call */
struct passwd *
getpwent()
{
int r;
static const ns_dtab dtab[] = {
NS_FILES_CB(_local_getpw, NULL)
NS_DNS_CB(_dns_getpw, NULL)
NS_NIS_CB(_nis_getpw, NULL)
NS_COMPAT_CB(_compat_getpwent, NULL)
{ 0 }
};
r = nsdispatch(NULL, dtab, NSDB_PASSWD, "getpwent", compatsrc,
_PW_KEYBYNUM);
if (r != NS_SUCCESS)
return (struct passwd *)NULL;
return &_pw_passwd;
}
The we have to implement _local_getpw, _dns_getpw, _nis_getpw,
and _compat_getpwent and make them behave as expected.
NetBSD seems to support having the passwd database on DNS using something
called HESIOD (I hadn't heard about it before). I don't think FreeBSD has
any sort of support for this.
*Step Three: Implement _ldap_getpw :)
If anyone has any comments, suggestions, etc. I would appreciate it.
Regards,
-Oscar
--
For PGP Public Key: finger oboni...@fisicc-ufm.edu
.\" $NetBSD: nsswitch.conf.5,v 1.14 1999/03/17 20:19:47 garbled Exp $
.\"
.\" Copyright (c) 1997, 1998, 1999 The NetBSD Foundation, Inc.
.\" All rights reserved.
.\"
.\" This code is derived from software contributed to The NetBSD Foundation
.\" by Luke Mewburn.
.\"
.\" Redistribution and use in source and binary forms, with or without
.\" modification, are permitted provided that the following conditions
.\" are met:
.\" 1. Redistributions of source code must retain the above copyright
.\" notice, this list of conditions and the following disclaimer.
.\" 2. Redistributions in binary form must reproduce the above copyright
.\" notice, this list of conditions and the following disclaimer in the
.\" documentation and/or other materials provided with the distribution.
.\" 3. All advertising materials mentioning features or use of this software
.\" must display the following acknowledgement:
.\" This product includes software developed by Luke Mewburn.
.\" 4. The name of the author may not be used to endorse or promote products
.\" derived from this software without specific prior written permission.
.\"
.\" THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
.\" IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
.\" OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
.\" IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
.\" INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING,
.\" BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS
.\" OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
.\" ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR
.\" TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE
.\" USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
.\"
.Dd January 22, 1998
.Dt NSSWITCH.CONF 5
.Os
.Sh NAME
.Nm nsswitch.conf
.Nd name-service switch configuration file
.Sh DESCRIPTION
The
.Nm
file specifies how the
.Xr nsdispatch 3
(name-service switch dispatcher) routines in the C library should operate.
.Pp
The configuration file controls how a process looks up various databases
containing information regarding hosts, users (passwords), groups,
netgroups, etc.
Each database comes from a source (such as local files, DNS, and
.Tn NIS ) ,
and the order to look up the sources is specified in
.Nm nsswitch.conf .
.Pp
Each entry in
.Nm
consists of a database name, and a space separated list of sources.
Each source can have an optional trailing criterion that determines
whether the next listed source is used, or the search terminates at
the current source.
Each criterion consists of one or more status codes, and actions to
take if that status code occurs.
.Ss Sources
The following sources are implemented:
.Bl -column "compat" -offset indent -compact
.Sy Source Description
.It files Local files, such as
.Pa /etc/hosts ,
and
.Pa /etc/passwd .
.It dns Internet Domain Name System.
.Dq hosts
and
.Sq networks
use
.Sy IN
class entries, all other databases use
.Sy HS
class (Hesiod) entries.
.It nis NIS (formerly YP)
.It compat support
.Sq
NSS Project
Following on the NSS (Name Service Switch):
*Step One: I ported the NetBSD implementation of nsdispatch(3) as implemented
by Luke Mewburn. See attached patch to libc and new header file. I'm also
attaching the man page for /etc/nsswitch.conf. Right now it compiles,
installs, and works for some simple tests I've run.
*Step Two: make getpwent, getgrent, and friends actually use the nsdispatch
function. I've already started looking at the source, but am having trouble
with the NIS part. Maybe someone more knowledgeable could write the NIS
function.
Basically we have to reduce each of the functions to a simple nsdispatch
call and then implement the real functions... Here's an example from
getpwent.c
/* Basically we reduce getpwent to a simple nsdispatch call */
struct passwd *
getpwent()
{
int r;
static const ns_dtab dtab[] = {
NS_FILES_CB(_local_getpw, NULL)
NS_DNS_CB(_dns_getpw, NULL)
NS_NIS_CB(_nis_getpw, NULL)
NS_COMPAT_CB(_compat_getpwent, NULL)
{ 0 }
};
r = nsdispatch(NULL, dtab, NSDB_PASSWD, "getpwent", compatsrc,
_PW_KEYBYNUM);
if (r != NS_SUCCESS)
return (struct passwd *)NULL;
return &_pw_passwd;
}
The we have to implement _local_getpw, _dns_getpw, _nis_getpw,
and _compat_getpwent and make them behave as expected.
NetBSD seems to support having the passwd database on DNS using something
called HESIOD (I hadn't heard about it before). I don't think FreeBSD has
any sort of support for this.
*Step Three: Implement _ldap_getpw :)
If anyone has any comments, suggestions, etc. I would appreciate it.
Regards,
-Oscar
--
For PGP Public Key: finger [EMAIL PROTECTED]
.\" $NetBSD: nsswitch.conf.5,v 1.14 1999/03/17 20:19:47 garbled Exp $
.\"
.\" Copyright (c) 1997, 1998, 1999 The NetBSD Foundation, Inc.
.\" All rights reserved.
.\"
.\" This code is derived from software contributed to The NetBSD Foundation
.\" by Luke Mewburn.
.\"
.\" Redistribution and use in source and binary forms, with or without
.\" modification, are permitted provided that the following conditions
.\" are met:
.\" 1. Redistributions of source code must retain the above copyright
.\" notice, this list of conditions and the following disclaimer.
.\" 2. Redistributions in binary form must reproduce the above copyright
.\" notice, this list of conditions and the following disclaimer in the
.\" documentation and/or other materials provided with the distribution.
.\" 3. All advertising materials mentioning features or use of this software
.\" must display the following acknowledgement:
.\" This product includes software developed by Luke Mewburn.
.\" 4. The name of the author may not be used to endorse or promote products
.\" derived from this software without specific prior written permission.
.\"
.\" THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
.\" IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
.\" OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
.\" IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
.\" INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING,
.\" BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS
.\" OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
.\" ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR
.\" TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE
.\" USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
.\"
.Dd January 22, 1998
.Dt NSSWITCH.CONF 5
.Os
.Sh NAME
.Nm nsswitch.conf
.Nd name-service switch configuration file
.Sh DESCRIPTION
The
.Nm
file specifies how the
.Xr nsdispatch 3
(name-service switch dispatcher) routines in the C library should operate.
.Pp
The configuration file controls how a process looks up various databases
containing information regarding hosts, users (passwords), groups,
netgroups, etc.
Each database comes from a source (such as local files, DNS, and
.Tn NIS ) ,
and the order to look up the sources is specified in
.Nm nsswitch.conf .
.Pp
Each entry in
.Nm
consists of a database name, and a space separated list of sources.
Each source can have an optional trailing criterion that determines
whether the next listed source is used, or the search terminates at
the current source.
Each criterion consists of one or more status codes, and actions to
take if that status code occurs.
.Ss Sources
The following sources are implemented:
.Bl -column "compat" -offset indent -compact
.Sy Source Description
.It files Local files, such as
.Pa /etc/hosts ,
and
.Pa /etc/passwd .
.It dns Internet Domain Name System.
.Dq hosts
and
.Sq networks
use
.Sy IN
class entries, all other databases use
.Sy HS
class (Hesiod) entries.
.It nis NIS (formerly YP)
.It compat support
.Sq +/
Re: PAM & LDAP in FreeBSD
On Wed, Jul 21, 1999 at 06:22:39PM +, Niall Smart wrote: > [ CC list nuked ] good! :) >> Ok, here goes my understanding of how things should be, please correct me >> if i'm wrong. >> >> There are three parts to the problem: >> >> 1. Where do we get the databases from? I mean, where do we get passwd, group, >>hosts, ethers, etc from. >> >>This should be handled by a name service switch a la solaris. Basically >>we want to be able to tell the system for each individual database where >>to get the stuff from. We can add entries for each database in the system. > > Not so much as "where do we get the databases from" as "which databases > hold data for this particular service". For example DNS can store > information for the hosts service (i.e. nameserver service) but could > also > store crytographic keys which could be used for as host keys for ssh for > example. The service has a standard API (gethostbyname() for example, > or > getpwnam()) which can search through multiple disparate database types. > > (I may be mixing my terminology up here, it may be more conventional > to say "which services support this database", where the database > might be a load of struct pw for example, but hopefully its clear I > mean) > > Each particular database type might have its own configuration file. > Taking the "hosts" service for example, the configuration file for > the DNS database is /etc/resolv.conf and there is no configuration > for the files database (which uses /etc/hosts) Agreed. How would the sysadmin configure the stuff? I mean, our design should be flexible enough to allow for the kind of stuff you're talking about. I personally would like to be able to configure everything in the system the following way: $ cat /etc/nsswitch.conf passwd= ldap files hosts= dns files group= ldap files traditional service = where db to get it from here passwd means stuff that's in struct passwd hosts meand hostname to IP mapping, and so on. $ cat /etc/ldap.conf host= ldap.fisicc-ufm.edu basedn= ou=staff, dc=fisicc-ufm, dc=edu username= uid passwd= userPassword uid= userId gid= groupId home= userHome shell= defaultShell this would be all the ldap configuration stuff, for instance, how to map the struct passwd entries to the ldap records. $ cat /etc/resolv.conf usual dns configuration stuff so we would end up having a singe configuration file (nsswitch.conf) telling the system where to get the info from and then individual configuration files telling the system how to configure each individual service. now... would we want to be able to pull this individual configuration files from a certain service? could I have /etc/resolv.conf pulled from ldap for example? > >> 2. How to authorize the user? I mean, what sort of authentication should we >>use to decide if the user should be allowed in. >> >>This should be handled by PAM. > > Yes, although login programs would require that a) getpwnam returns > non-NULL and b) pam_authenticate returns PAM_SUCCESS. > this is what started the thread. I installed a pam_ldap module only to find out that login wouldn't let the user in because getpwnam returned NULL (not found on /etc/passwd). I then asked: "what would happen if login were to succeed, but once the user has logged in he/she doesn't have a username to uid mapping?" >> 3. What password hash should we use when we have the username and the >>password hash? >> >>This should be handled by the new modularized crypt. > > This is a function of the pam_unix module, a PAM module can > use smartcards, retina scanners, body odour detectors etc etc, > so it may not use password hashes at all. Each PAM module may > have its own configuration file to tell it which serial port the > smartcard reader is on for example. I don't see where the modularized crypt would fit in then... i totally agree that pam has this capability i was just trying to fit in the crypt stuff people have been working on. do I make sense? Regards, -Oscar -- For PGP Public Key: finger oboni...@fisicc-ufm.edu To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: PAM & LDAP in FreeBSD
On Thu, Jul 22, 1999 at 01:00:57AM +0900, Daniel C. Sobral wrote: > Oscar Bonilla wrote: >> >> There are three parts to the problem: >> >> 1. Where do we get the databases from? I mean, where do we get passwd, group, >>hosts, ethers, etc from. >> >>This should be handled by a name service switch a la solaris. Basically >>we want to be able to tell the system for each individual database where >>to get the stuff from. We can add entries for each database in the system. > > I perceive here an unfair biasing toward nss. Someone mentioned > defining where to get the passwords from based on the login class. > This is a very interesting option, that doesn't seem to be well > served by nss. > I was actually talking about the "other" entries. usename:uid:gid:gecos:home:shell where does PAM fit in the schema you talk about? would we need to make PAM login.conf aware then? Where do we get login.conf from? from nsswitch.conf? Regards, -Oscar -- For PGP Public Key: finger oboni...@fisicc-ufm.edu To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: PAM & LDAP in FreeBSD
On Wed, Jul 21, 1999 at 06:22:39PM +, Niall Smart wrote: > [ CC list nuked ] good! :) >> Ok, here goes my understanding of how things should be, please correct me >> if i'm wrong. >> >> There are three parts to the problem: >> >> 1. Where do we get the databases from? I mean, where do we get passwd, group, >>hosts, ethers, etc from. >> >>This should be handled by a name service switch a la solaris. Basically >>we want to be able to tell the system for each individual database where >>to get the stuff from. We can add entries for each database in the system. > > Not so much as "where do we get the databases from" as "which databases > hold data for this particular service". For example DNS can store > information for the hosts service (i.e. nameserver service) but could > also > store crytographic keys which could be used for as host keys for ssh for > example. The service has a standard API (gethostbyname() for example, > or > getpwnam()) which can search through multiple disparate database types. > > (I may be mixing my terminology up here, it may be more conventional > to say "which services support this database", where the database > might be a load of struct pw for example, but hopefully its clear I > mean) > > Each particular database type might have its own configuration file. > Taking the "hosts" service for example, the configuration file for > the DNS database is /etc/resolv.conf and there is no configuration > for the files database (which uses /etc/hosts) Agreed. How would the sysadmin configure the stuff? I mean, our design should be flexible enough to allow for the kind of stuff you're talking about. I personally would like to be able to configure everything in the system the following way: $ cat /etc/nsswitch.conf passwd= ldap files hosts= dns files group= ldap files traditional service = where db to get it from here passwd means stuff that's in struct passwd hosts meand hostname to IP mapping, and so on. $ cat /etc/ldap.conf host= ldap.fisicc-ufm.edu basedn= ou=staff, dc=fisicc-ufm, dc=edu username= uid passwd= userPassword uid= userId gid= groupId home= userHome shell= defaultShell this would be all the ldap configuration stuff, for instance, how to map the struct passwd entries to the ldap records. $ cat /etc/resolv.conf usual dns configuration stuff so we would end up having a singe configuration file (nsswitch.conf) telling the system where to get the info from and then individual configuration files telling the system how to configure each individual service. now... would we want to be able to pull this individual configuration files from a certain service? could I have /etc/resolv.conf pulled from ldap for example? > >> 2. How to authorize the user? I mean, what sort of authentication should we >>use to decide if the user should be allowed in. >> >>This should be handled by PAM. > > Yes, although login programs would require that a) getpwnam returns > non-NULL and b) pam_authenticate returns PAM_SUCCESS. > this is what started the thread. I installed a pam_ldap module only to find out that login wouldn't let the user in because getpwnam returned NULL (not found on /etc/passwd). I then asked: "what would happen if login were to succeed, but once the user has logged in he/she doesn't have a username to uid mapping?" >> 3. What password hash should we use when we have the username and the >>password hash? >> >>This should be handled by the new modularized crypt. > > This is a function of the pam_unix module, a PAM module can > use smartcards, retina scanners, body odour detectors etc etc, > so it may not use password hashes at all. Each PAM module may > have its own configuration file to tell it which serial port the > smartcard reader is on for example. I don't see where the modularized crypt would fit in then... i totally agree that pam has this capability i was just trying to fit in the crypt stuff people have been working on. do I make sense? Regards, -Oscar -- For PGP Public Key: finger [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PAM & LDAP in FreeBSD
On Wed, Jul 21, 1999 at 01:46:56AM +0930, Kris Kennaway wrote: > It looks like we've got some good concurrent projects happening at the > moment - markm and co working on PAM, the nsswitch.conf project you're > talking about, and the stuff I'm working on with modularizing crypt() and > supporting per-login class password hashes (I've rewritten the library > since I last posted about it and expect to have my code cleaned up by > tomorrow night for another snapshot). > > The thing to make sure is that we don't tread on each other's toes, and > basically that we look for the big picture and how all these projects fit > together. Ok, here goes my understanding of how things should be, please correct me if i'm wrong. There are three parts to the problem: 1. Where do we get the databases from? I mean, where do we get passwd, group, hosts, ethers, etc from. This should be handled by a name service switch a la solaris. Basically we want to be able to tell the system for each individual database where to get the stuff from. We can add entries for each database in the system. 2. How to authorize the user? I mean, what sort of authentication should we use to decide if the user should be allowed in. This should be handled by PAM. 3. What password hash should we use when we have the username and the password hash? This should be handled by the new modularized crypt. Do we want to be able to tell the system where to get its pam.conf and login.conf from? This would mean having a pam.conf and login.conf entry in nsswitch.conf. Can we make a list of stuff that needs to be done to make this possible? Something like a tasklist would be good. a) design and implement a name service switch. b) make libc aware of the name service switch. c) ??? then we should detail each step... Regards, -Oscar -- For PGP Public Key: finger oboni...@fisicc-ufm.edu To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: PAM & LDAP in FreeBSD
On Thu, Jul 22, 1999 at 01:00:57AM +0900, Daniel C. Sobral wrote: > Oscar Bonilla wrote: >> >> There are three parts to the problem: >> >> 1. Where do we get the databases from? I mean, where do we get passwd, group, >>hosts, ethers, etc from. >> >>This should be handled by a name service switch a la solaris. Basically >>we want to be able to tell the system for each individual database where >>to get the stuff from. We can add entries for each database in the system. > > I perceive here an unfair biasing toward nss. Someone mentioned > defining where to get the passwords from based on the login class. > This is a very interesting option, that doesn't seem to be well > served by nss. > I was actually talking about the "other" entries. usename:uid:gid:gecos:home:shell where does PAM fit in the schema you talk about? would we need to make PAM login.conf aware then? Where do we get login.conf from? from nsswitch.conf? Regards, -Oscar -- For PGP Public Key: finger [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PAM & LDAP in FreeBSD
On Wed, Jul 21, 1999 at 01:46:56AM +0930, Kris Kennaway wrote: > It looks like we've got some good concurrent projects happening at the > moment - markm and co working on PAM, the nsswitch.conf project you're > talking about, and the stuff I'm working on with modularizing crypt() and > supporting per-login class password hashes (I've rewritten the library > since I last posted about it and expect to have my code cleaned up by > tomorrow night for another snapshot). > > The thing to make sure is that we don't tread on each other's toes, and > basically that we look for the big picture and how all these projects fit > together. Ok, here goes my understanding of how things should be, please correct me if i'm wrong. There are three parts to the problem: 1. Where do we get the databases from? I mean, where do we get passwd, group, hosts, ethers, etc from. This should be handled by a name service switch a la solaris. Basically we want to be able to tell the system for each individual database where to get the stuff from. We can add entries for each database in the system. 2. How to authorize the user? I mean, what sort of authentication should we use to decide if the user should be allowed in. This should be handled by PAM. 3. What password hash should we use when we have the username and the password hash? This should be handled by the new modularized crypt. Do we want to be able to tell the system where to get its pam.conf and login.conf from? This would mean having a pam.conf and login.conf entry in nsswitch.conf. Can we make a list of stuff that needs to be done to make this possible? Something like a tasklist would be good. a) design and implement a name service switch. b) make libc aware of the name service switch. c) ??? then we should detail each step... Regards, -Oscar -- For PGP Public Key: finger [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PAM & LDAP in FreeBSD
On Tue, Jul 20, 1999 at 11:49:42AM -0700, John Polstra wrote: > In article <19990720082825.b...@fisicc-ufm.edu>, > Oscar Bonilla wrote: > > > Couldn't we do this with /etc/auth.conf? > > The plan when PAM was brought in was to eliminate auth.conf. I don't > think we should be looking for new uses for it. > ok, so this clarifies a lot of things... let's get rid of /etc/auth.conf and go with /etc/pam.conf for the authentication and /etc/nsswitch.conf for the info on where to obtain the databases from. Regards, -Oscar -- For PGP Public Key: finger oboni...@fisicc-ufm.edu To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: PAM & LDAP in FreeBSD
> It looks like we've got some good concurrent projects happening at the > moment - markm and co working on PAM, the nsswitch.conf project you're > talking about, and the stuff I'm working on with modularizing crypt() and > supporting per-login class password hashes (I've rewritten the library > since I last posted about it and expect to have my code cleaned up by > tomorrow night for another snapshot). > > The thing to make sure is that we don't tread on each other's toes, and > basically that we look for the big picture and how all these projects fit > together. > Ok, this is my understanding of the thing: There are two parts to the problem, first we need a way to tell the system where to get its information from (call them databases, tables or whatever). This should be done a la solaris, with /etc/nsswitch.conf telling if this is to be fetched from "files, ldap, nis, dns, etc". We need to recode all the programs that obtain this info directly from files to get it from a library (this would be nsd). And then code the library itself to get the info from /etc/nsswitch.conf Second, we need a way to authenticate the user... this is what PAM does. What would need to be done is change the pam modules to make them nsd aware (i.e. where should I get the passwd from?) or make them /etc/auth.conf aware? this is the confusing part... where does crypt fit into this? crypt would get what from /etc/login.conf? regards, -Oscar -- For PGP Public Key: finger oboni...@fisicc-ufm.edu To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: PAM & LDAP in FreeBSD
On Tue, Jul 20, 1999 at 11:49:42AM -0700, John Polstra wrote: > In article <[EMAIL PROTECTED]>, > Oscar Bonilla <[EMAIL PROTECTED]> wrote: > > > Couldn't we do this with /etc/auth.conf? > > The plan when PAM was brought in was to eliminate auth.conf. I don't > think we should be looking for new uses for it. > ok, so this clarifies a lot of things... let's get rid of /etc/auth.conf and go with /etc/pam.conf for the authentication and /etc/nsswitch.conf for the info on where to obtain the databases from. Regards, -Oscar -- For PGP Public Key: finger [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PAM & LDAP in FreeBSD
> It looks like we've got some good concurrent projects happening at the > moment - markm and co working on PAM, the nsswitch.conf project you're > talking about, and the stuff I'm working on with modularizing crypt() and > supporting per-login class password hashes (I've rewritten the library > since I last posted about it and expect to have my code cleaned up by > tomorrow night for another snapshot). > > The thing to make sure is that we don't tread on each other's toes, and > basically that we look for the big picture and how all these projects fit > together. > Ok, this is my understanding of the thing: There are two parts to the problem, first we need a way to tell the system where to get its information from (call them databases, tables or whatever). This should be done a la solaris, with /etc/nsswitch.conf telling if this is to be fetched from "files, ldap, nis, dns, etc". We need to recode all the programs that obtain this info directly from files to get it from a library (this would be nsd). And then code the library itself to get the info from /etc/nsswitch.conf Second, we need a way to authenticate the user... this is what PAM does. What would need to be done is change the pam modules to make them nsd aware (i.e. where should I get the passwd from?) or make them /etc/auth.conf aware? this is the confusing part... where does crypt fit into this? crypt would get what from /etc/login.conf? regards, -Oscar -- For PGP Public Key: finger [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PAM & LDAP in FreeBSD
On Tue, Jul 20, 1999 at 10:59:30PM +1200, Joe Abley wrote: > On Mon, Jul 19, 1999 at 06:00:26PM -0600, Oscar Bonilla wrote: > > I agree. In solaris (and linux by the way) all you do is set > > passwd ldap files > > in /etc/nsswitch.conf > > and that's it. > > In Solaris, it's > > passwd: ldap files > ^ > > nsswitch.conf(4), SunOS 5.5.1: > > ... > There is an entry in /etc/nsswitch.conf for each database. > Typically these entries will be simple, such as "protocols: > files" or "networks: files nisplus". However, when multiple > sources are specified it is sometimes necessary to define > precisely the circumstances under which each source will be > tried. A source can return one of the following codes: > > Status Meaning > SUCCESS Requested database entry was found > UNAVAIL Source is not responding or corrupted > NOTFOUNDSource responded "no such entry" > TRYAGAINSource is busy, might respond to > retries > > For each status code, two actions are possible: > > Action Meaning > continueTry the next source in the list > return Return now > > The complete syntax of an entry is > > ::= ":" [ []]* >::= "[" + "]" > ::= "=" > ::= "success" | "notfound" | "unavail" | "tryagain" > ::= "return" | "continue" > ... > > Actually, this message is now bordering on the useful, when all I meant > to be was pedantic. I'll stop now, before I go too far; suffice to say > the Solaris implementation has some other elements worthy of consideration > if compatability is worth aiming for. > > It's maybe worth mentioning that /etc/host.conf might be a candidate for > the attic if the Solaris implementation was adopted on a wholesale basis > (i.e. including the "hosts:" key). > Couldn't we do this with /etc/auth.conf? What's the real purpose of this file? From the man page: "auth.conf contains various attributes important to the authentication code, most notably kerberos(5) for the time being." Isn't this what PAM is about? authentication? or does auth.conf cover the "other" part of authentication, basically the getpw* stuff? Regards, -Oscar -- For PGP Public Key: finger oboni...@fisicc-ufm.edu To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: PAM & LDAP in FreeBSD
On Tue, Jul 20, 1999 at 10:59:30PM +1200, Joe Abley wrote: > On Mon, Jul 19, 1999 at 06:00:26PM -0600, Oscar Bonilla wrote: > > I agree. In solaris (and linux by the way) all you do is set > > passwd ldap files > > in /etc/nsswitch.conf > > and that's it. > > In Solaris, it's > > passwd: ldap files > ^ > > nsswitch.conf(4), SunOS 5.5.1: > > ... > There is an entry in /etc/nsswitch.conf for each database. > Typically these entries will be simple, such as "protocols: > files" or "networks: files nisplus". However, when multiple > sources are specified it is sometimes necessary to define > precisely the circumstances under which each source will be > tried. A source can return one of the following codes: > > Status Meaning > SUCCESS Requested database entry was found > UNAVAIL Source is not responding or corrupted > NOTFOUNDSource responded "no such entry" > TRYAGAINSource is busy, might respond to > retries > > For each status code, two actions are possible: > > Action Meaning > continueTry the next source in the list > return Return now > > The complete syntax of an entry is > > ::= ":" [ []]* >::= "[" + "]" > ::= "=" > ::= "success" | "notfound" | "unavail" | "tryagain" > ::= "return" | "continue" > ... > > Actually, this message is now bordering on the useful, when all I meant > to be was pedantic. I'll stop now, before I go too far; suffice to say > the Solaris implementation has some other elements worthy of consideration > if compatability is worth aiming for. > > It's maybe worth mentioning that /etc/host.conf might be a candidate for > the attic if the Solaris implementation was adopted on a wholesale basis > (i.e. including the "hosts:" key). > Couldn't we do this with /etc/auth.conf? What's the real purpose of this file? From the man page: "auth.conf contains various attributes important to the authentication code, most notably kerberos(5) for the time being." Isn't this what PAM is about? authentication? or does auth.conf cover the "other" part of authentication, basically the getpw* stuff? Regards, -Oscar -- For PGP Public Key: finger [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PAM & LDAP in FreeBSD
On Mon, Jul 19, 1999 at 04:51:12PM -0600, Wes Peters wrote: > The implementation details are as unimportant as ever: they have to work > and be maintainable. Following prior art remains a good idea; the Solaris > "name service switch" implementation is a good starting point to consider. > I agree. In solaris (and linux by the way) all you do is set passwd ldap files in /etc/nsswitch.conf and that's it. I had started to write the code to mess with libc to "fix" the getpwent stuff, but a better solution is to "port" the nsswitch stuff from linux (i don't have source from solaris :) Anyone more knowledgeable should give me a big hand here and point me to the right way to start this. I'm willing to do the coding but need help on the overall design. Since I need this working asap, I'm gonna hack libc so that if the file /etc/auth.conf has a line saying auth_list = ldap, it looks in /etc/ldap.conf to get the rest of the stuff (server, port, base dn, etc). At the same time, we should work towards a real solution. regards, -Oscar -- For PGP Public Key: finger oboni...@fisicc-ufm.edu To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: PAM & LDAP in FreeBSD
On Mon, Jul 19, 1999 at 04:51:12PM -0600, Wes Peters wrote: > The implementation details are as unimportant as ever: they have to work > and be maintainable. Following prior art remains a good idea; the Solaris > "name service switch" implementation is a good starting point to consider. > I agree. In solaris (and linux by the way) all you do is set passwd ldap files in /etc/nsswitch.conf and that's it. I had started to write the code to mess with libc to "fix" the getpwent stuff, but a better solution is to "port" the nsswitch stuff from linux (i don't have source from solaris :) Anyone more knowledgeable should give me a big hand here and point me to the right way to start this. I'm willing to do the coding but need help on the overall design. Since I need this working asap, I'm gonna hack libc so that if the file /etc/auth.conf has a line saying auth_list = ldap, it looks in /etc/ldap.conf to get the rest of the stuff (server, port, base dn, etc). At the same time, we should work towards a real solution. regards, -Oscar -- For PGP Public Key: finger [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PAM & LDAP in FreeBSD
On Mon, Jul 19, 1999 at 06:13:51PM +0200, Dag-Erling Smorgrav wrote: > Oscar Bonilla writes: > > the idea is to have an entry in the /etc/passwd enabling LDAP lookups. > > the Entry would be of the form > > > > ldap:*:389:389:o=My Organization, c=BR:uid:ldap.myorg.com > > Horrible idea. > suggestions? -Oscar -- For PGP Public Key: finger oboni...@fisicc-ufm.edu To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: PAM & LDAP in FreeBSD
On Mon, Jul 19, 1999 at 06:13:51PM +0200, Dag-Erling Smorgrav wrote: > Oscar Bonilla <[EMAIL PROTECTED]> writes: > > the idea is to have an entry in the /etc/passwd enabling LDAP lookups. > > the Entry would be of the form > > > > ldap:*:389:389:o=My Organization, c=BR:uid:ldap.myorg.com > > Horrible idea. > suggestions? -Oscar -- For PGP Public Key: finger [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PAM & LDAP in FreeBSD
Following up on my own post:
For LDAP to be seamlessly integrated into the system some of the libraries
have to be changed. Specifically the ones dealing with /etc/passwd and
user information.
I've decided the best way to do this is to do what's done with NIS.
Basically handle the case where the user is not available in the local
databases.
the idea is to have an entry in the /etc/passwd enabling LDAP lookups.
the Entry would be of the form
ldap:*:389:389:o=My Organization, c=BR:uid:ldap.myorg.com
^^^ ^^^ ^^^ ^^
| |||
portbase dnattr LDAP Server
This comes ftom a pam_ldap module I got from Pedro A M Vazquez
I'll change all of the function in lib/libc/gen/getpwent.c to handle this
special case.
The only problem is that openldap has to be integrated on the base system
for this to compile... can I safely copy it to /usr/src/contrib?
How do I submit this after it's done? anyone cares about ldap :)?
Regards,
-Oscar
On Thu, Jul 15, 1999 at 08:03:36PM -0600, Oscar Bonilla wrote:
> While trying to use the pam_ldap module available from www.padl.com
> I discovered the following problem.
>
> although the module authenticates just fine (using openldap)
> the login program fails to permit logins. I traced the problem to
> login.c --- the following code is from login.c
>
> my questions are at the bottom.
>
>
>
>
> pwd = getpwnam(username);
>
> - at this point pwd == NULL due to the fact that the user
> - does not exist on the local passwd database... see below
>
> /*
>* if we have a valid account name, and it doesn't have a
>* password, or the -f option was specified and the caller
>* is root or the caller isn't changing their uid, don't
>* authenticate.
>*/
> if (pwd != NULL) {
> if (pwd->pw_uid == 0)
> rootlogin = 1;
>
> if (fflag && (uid == (uid_t)0 ||
> uid == (uid_t)pwd->pw_uid)) {
> /* already authenticated */
> break;
> } else if (pwd->pw_passwd[0] == '\0') {
> if (!rootlogin || rootok) {
> /* pretend password okay */
> rval = 0;
> goto ttycheck;
> }
> }
> }
>
> fflag = 0;
>
> (void)setpriority(PRIO_PROCESS, 0, -4);
>
> #ifndef NO_PAM
> /*
>* Try to authenticate using PAM. If a PAM system error
>* occurs, perhaps because of a botched configuration,
>* then fall back to using traditional Unix authentication.
>*/
> if ((rval = auth_pam()) == -1)
>
> - This returns PAM_SUCCESS since the pam_ldap module has
> - successfully identified and authenticated the user.
>
> #endif /* NO_PAM */
> rval = auth_traditional();
>
> (void)setpriority(PRIO_PROCESS, 0, 0);
>
> #ifndef NO_PAM
> /*
>* PAM authentication may have changed "pwd" to the
>* entry for the template user. Check again to see if
>* this is a root login after all.
>*/
> if (pwd != NULL && pwd->pw_uid == 0)
> rootlogin = 1;
> #endif /* NO_PAM */
>
> ttycheck:
> /*
>* If trying to log in as root without Kerberos,
>* but with insecure terminal, refuse the login attempt.
>*/
>
> - This next if is the problem: pwd == NULL from above,
> - and the user doesn't get in.
>
> if (pwd && !rval) {
> if (rootlogin && !rootok)
> refused(NULL, "NOROOT", 0);
> else/* valid password & authenticated */
> break;
> }
>
> (void)printf("Login incorrect\n");
> failures++;
>
>
>
> 1. what would be the rig
Re: PAM & LDAP in FreeBSD
Following up on my own post:
For LDAP to be seamlessly integrated into the system some of the libraries
have to be changed. Specifically the ones dealing with /etc/passwd and
user information.
I've decided the best way to do this is to do what's done with NIS.
Basically handle the case where the user is not available in the local
databases.
the idea is to have an entry in the /etc/passwd enabling LDAP lookups.
the Entry would be of the form
ldap:*:389:389:o=My Organization, c=BR:uid:ldap.myorg.com
^^^ ^^^ ^^^ ^^
| |||
portbase dnattr LDAP Server
This comes ftom a pam_ldap module I got from Pedro A M Vazquez
<[EMAIL PROTECTED]>
I'll change all of the function in lib/libc/gen/getpwent.c to handle this
special case.
The only problem is that openldap has to be integrated on the base system
for this to compile... can I safely copy it to /usr/src/contrib?
How do I submit this after it's done? anyone cares about ldap :)?
Regards,
-Oscar
On Thu, Jul 15, 1999 at 08:03:36PM -0600, Oscar Bonilla wrote:
> While trying to use the pam_ldap module available from www.padl.com
> I discovered the following problem.
>
> although the module authenticates just fine (using openldap)
> the login program fails to permit logins. I traced the problem to
> login.c --- the following code is from login.c
>
> my questions are at the bottom.
>
>
>
>
> pwd = getpwnam(username);
>
> - at this point pwd == NULL due to the fact that the user
> - does not exist on the local passwd database... see below
>
> /*
>* if we have a valid account name, and it doesn't have a
>* password, or the -f option was specified and the caller
>* is root or the caller isn't changing their uid, don't
>* authenticate.
>*/
> if (pwd != NULL) {
> if (pwd->pw_uid == 0)
> rootlogin = 1;
>
> if (fflag && (uid == (uid_t)0 ||
> uid == (uid_t)pwd->pw_uid)) {
> /* already authenticated */
> break;
> } else if (pwd->pw_passwd[0] == '\0') {
> if (!rootlogin || rootok) {
> /* pretend password okay */
> rval = 0;
> goto ttycheck;
> }
> }
> }
>
> fflag = 0;
>
> (void)setpriority(PRIO_PROCESS, 0, -4);
>
> #ifndef NO_PAM
> /*
>* Try to authenticate using PAM. If a PAM system error
>* occurs, perhaps because of a botched configuration,
>* then fall back to using traditional Unix authentication.
>*/
> if ((rval = auth_pam()) == -1)
>
> - This returns PAM_SUCCESS since the pam_ldap module has
> - successfully identified and authenticated the user.
>
> #endif /* NO_PAM */
> rval = auth_traditional();
>
> (void)setpriority(PRIO_PROCESS, 0, 0);
>
> #ifndef NO_PAM
> /*
>* PAM authentication may have changed "pwd" to the
>* entry for the template user. Check again to see if
>* this is a root login after all.
>*/
> if (pwd != NULL && pwd->pw_uid == 0)
> rootlogin = 1;
> #endif /* NO_PAM */
>
> ttycheck:
> /*
>* If trying to log in as root without Kerberos,
>* but with insecure terminal, refuse the login attempt.
>*/
>
> - This next if is the problem: pwd == NULL from above,
> - and the user doesn't get in.
>
> if (pwd && !rval) {
> if (rootlogin && !rootok)
> refused(NULL, "NOROOT", 0);
> else/* valid password & authenticated */
> break;
> }
>
> (void)printf("Login incorrect\n");
> failures++;
>
>
>
&g
PAM & LDAP in FreeBSD
While trying to use the pam_ldap module available from www.padl.com
I discovered the following problem.
although the module authenticates just fine (using openldap)
the login program fails to permit logins. I traced the problem to
login.c --- the following code is from login.c
my questions are at the bottom.
pwd = getpwnam(username);
- at this point pwd == NULL due to the fact that the user
- does not exist on the local passwd database... see below
/*
* if we have a valid account name, and it doesn't have a
* password, or the -f option was specified and the caller
* is root or the caller isn't changing their uid, don't
* authenticate.
*/
if (pwd != NULL) {
if (pwd->pw_uid == 0)
rootlogin = 1;
if (fflag && (uid == (uid_t)0 ||
uid == (uid_t)pwd->pw_uid)) {
/* already authenticated */
break;
} else if (pwd->pw_passwd[0] == '\0') {
if (!rootlogin || rootok) {
/* pretend password okay */
rval = 0;
goto ttycheck;
}
}
}
fflag = 0;
(void)setpriority(PRIO_PROCESS, 0, -4);
#ifndef NO_PAM
/*
* Try to authenticate using PAM. If a PAM system error
* occurs, perhaps because of a botched configuration,
* then fall back to using traditional Unix authentication.
*/
if ((rval = auth_pam()) == -1)
- This returns PAM_SUCCESS since the pam_ldap module has
- successfully identified and authenticated the user.
#endif /* NO_PAM */
rval = auth_traditional();
(void)setpriority(PRIO_PROCESS, 0, 0);
#ifndef NO_PAM
/*
* PAM authentication may have changed "pwd" to the
* entry for the template user. Check again to see if
* this is a root login after all.
*/
if (pwd != NULL && pwd->pw_uid == 0)
rootlogin = 1;
#endif /* NO_PAM */
ttycheck:
/*
* If trying to log in as root without Kerberos,
* but with insecure terminal, refuse the login attempt.
*/
- This next if is the problem: pwd == NULL from above,
- and the user doesn't get in.
if (pwd && !rval) {
if (rootlogin && !rootok)
refused(NULL, "NOROOT", 0);
else/* valid password & authenticated */
break;
}
(void)printf("Login incorrect\n");
failures++;
1. what would be the right way to fix this?
2. after the user successfully logs in he still won't have an entry
in the /etc/passwd database, so all syscalls having to do with
identifying the user will fail... how can I have these funcions get
their info from LDAP?
I'm willing to patch and submit these programs, but would like some
feedback about the right way to integrate this.
I checked with a friend who uses linux, and it appears linux doesn't have
this problem since they use the /etc/nsswithc.conf to tell the system
where to get info from. The nsswitch (resolver?) thing seems to
understand ldap.
Thanks folks,
-Oscar
--
For PGP Public Key: finger oboni...@fisicc-ufm.edu
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
PAM & LDAP in FreeBSD
While trying to use the pam_ldap module available from www.padl.com
I discovered the following problem.
although the module authenticates just fine (using openldap)
the login program fails to permit logins. I traced the problem to
login.c --- the following code is from login.c
my questions are at the bottom.
pwd = getpwnam(username);
- at this point pwd == NULL due to the fact that the user
- does not exist on the local passwd database... see below
/*
* if we have a valid account name, and it doesn't have a
* password, or the -f option was specified and the caller
* is root or the caller isn't changing their uid, don't
* authenticate.
*/
if (pwd != NULL) {
if (pwd->pw_uid == 0)
rootlogin = 1;
if (fflag && (uid == (uid_t)0 ||
uid == (uid_t)pwd->pw_uid)) {
/* already authenticated */
break;
} else if (pwd->pw_passwd[0] == '\0') {
if (!rootlogin || rootok) {
/* pretend password okay */
rval = 0;
goto ttycheck;
}
}
}
fflag = 0;
(void)setpriority(PRIO_PROCESS, 0, -4);
#ifndef NO_PAM
/*
* Try to authenticate using PAM. If a PAM system error
* occurs, perhaps because of a botched configuration,
* then fall back to using traditional Unix authentication.
*/
if ((rval = auth_pam()) == -1)
- This returns PAM_SUCCESS since the pam_ldap module has
- successfully identified and authenticated the user.
#endif /* NO_PAM */
rval = auth_traditional();
(void)setpriority(PRIO_PROCESS, 0, 0);
#ifndef NO_PAM
/*
* PAM authentication may have changed "pwd" to the
* entry for the template user. Check again to see if
* this is a root login after all.
*/
if (pwd != NULL && pwd->pw_uid == 0)
rootlogin = 1;
#endif /* NO_PAM */
ttycheck:
/*
* If trying to log in as root without Kerberos,
* but with insecure terminal, refuse the login attempt.
*/
- This next if is the problem: pwd == NULL from above,
- and the user doesn't get in.
if (pwd && !rval) {
if (rootlogin && !rootok)
refused(NULL, "NOROOT", 0);
else/* valid password & authenticated */
break;
}
(void)printf("Login incorrect\n");
failures++;
1. what would be the right way to fix this?
2. after the user successfully logs in he still won't have an entry
in the /etc/passwd database, so all syscalls having to do with
identifying the user will fail... how can I have these funcions get
their info from LDAP?
I'm willing to patch and submit these programs, but would like some
feedback about the right way to integrate this.
I checked with a friend who uses linux, and it appears linux doesn't have
this problem since they use the /etc/nsswithc.conf to tell the system
where to get info from. The nsswitch (resolver?) thing seems to
understand ldap.
Thanks folks,
-Oscar
--
For PGP Public Key: finger [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
