On Wed, Jul 21, 1999 at 06:22:39PM +0000, 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
