On Wed, Sep 29, 2004 at 04:03:59PM +0200, Ivan Popov wrote:
> Inspired by M.Kondrin's letter.
> 
> May be it will make the sense of the setup design more evident,
> if I try to describe a hypothetical but totally sane setup, based on Coda:
> 
> - clients have pam_aware login, which uses pam_something module
>   to check if a certain user "name" knows her password
> 
> - another pam module tells if a certain user "name"
>   may use the relevant host
> 
>   Note, pam_something can be (Kerberos, NIS, anything) based, but it is always
>   one and only function "name" => YES or NO
>   YES == ("is who she pretends to be" AND "is allowed to use this host")
> 
> if YES:
> - the login program just PICKS UP THE NEXT UNUSED UID (it does not matter
>   which uid, just let it be unused until then and afterwards, with 2^64
>   uids it is more or less infinite)
>   of course it logs which name corresponds to the uid, to be able
>   to identify processes afterwards.
>   it may create a corresponding new /etc/passwd entry, and even reuse it
>   at new logins with the same name.
>   only the numeric uid and user "name" are relevant there,
>   and can be lost without any harm (as long as the uids never are reused)
>   To be clear, uids make sense inside each host,
>   no reason to synchronize between hosts.
> 
> - the login program looks up (may be by some pam_somethingelse) the
>   homedir path corresponding to the user "name"

The login program need know nothing about this.... I believe this could
be accomplished with a "libnss_superdooperldap" library, along with some
extensions to NSCD (name service switch cache daemon).

I'm using libnss_ldap right now, with static mappings of
username->userid, but there's no reason a cache daemon running on the
local machine couldn't be responsible for allocating a local UID, and
local GID's for the groups the user is in.

You *could* do pam_ldap for auth, but I think it would be better in the
long run to use kerberos. The systems I admin at work use libnss_ldap
for anythign that would do 'getpwent' & friends, and use pam_krb5 (and
then pam_openafs_session) to get the user authenticated and access to
the filesystem.