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
