Date: Fri, 16 Mar 2001 21:43:48 -0800 From: Jack Rusher <jar@integratus.com> To: "David E. Cross" <crossd@cs.rpi.edu> Cc: freebsd-arch@freebsd.org Subject: Re: idle wonderings about 'struct pcred' Message-ID: <3AB2F994.8F64924@integratus.com> References: <200103170309.WAA92739@cs.rpi.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
"David E. Cross" wrote: > > authentication modules. We do need some basic set of APIs (to do > reference counting, etc... see email to Terry Lambert), but we need to Sure, I see the design philosophy that you have in mind for this. It should work well for what you have in mind, but might not do what I need. > I certainly would be interested in a NIS replacement. I wouldn't worry > about it conflicting with PAM, they answer fundamentally different questions. > PAM is a method for authenticating a user/service. NIS and its cousins is > a method of distributing database type information. The way computers work > there is some overlap between PAM and NIS (I need to know user 'X's password, > I look it up in some form of database). I wasn't suggesting PAM was a replacement for NIS. I was asking whether people would be interested in having additional auth information in the kernel, or whether they would rather see all such things constrained to PAM modules. Some of the services I would like to use with my network authentication system include a novel network filesystem layer that doesn't have a trust model that implicitly assumes client kernels are telling the truth. This may require kernel access to PKI routines to work properly--that's why I am considering a model that allows loadable crypto modules to be accessed directly from the kernel. Thanks, Jack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3AB2F994.8F64924>