(Illustration by Gaich Muramatsu)
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 extracts the Coda realm from the homedir path and asks the user for the corresponding Coda password (it may as well try the one supplied at login) and authenticates against that Coda realm (presumably by pam_codasomething) and runs /bin/sh "homedir"/.profile as the allocated uid The rest is responsibility of the user and her helpdesk, to provide a .profile which starts a nice environment, from Coda (not hypothetical, see /coda/konvalo.org) Note that as the Workstations Administrator you have to make very clear choices and take some actions, but not more than: - have an authentication database which can securely check if a person knows the password for some "name". Kerberos does it well. - have an algorithm to decide _after_ _successful_ authentication if _that_ "name" is allowed to run on _this_ host, it is doable say by pam_list combined with a cfengine distributing the list of allowed users (differing possibly on different hosts) - have an algorithm to map "name" => "homedir", which can be done statically or be distributed along with the allowed-users list (only 2 fields, "name" and "homedir") - have a working Coda client on each host - force all users into having their homedirs on Coda Then as a Filespace Administrator you can decide how to grant Coda file space to your users and how to protect their data. It is here you will manage volumes, Coda groups and acls. Totally independently of the client hosts administration above, except for adding new user names in both places. Don't care of allocating uids, Coda uids are used only for Coda internal bookkeeping, it will reserve new ones as needed. Done. As you see, no per-user information except a bit "allowed" and a string "homedir" is necessary on any workstation. No software is necessary locally either :) It's like the above I am running my workstations, and I hope it helps to see the essential properties and distinguish them from the (broken) traditionally accepted design... One "problem" with the above will be that ls -l will not show anything reasonable as "owner" or "group", but it is ok, as that is totally irrelevant on Coda. Happy Coda-ing, -- IvanReceived on 2004-09-29 10:04:41