On Sun, Jun 24, 2001 at 10:02:05PM -0700, Andrew Morgan wrote: > Adam Slattery wrote: > > This thread could get very messy... :) > > Yes. > > I feel a little nostalgic seeing this thread. It is essentially a > revisit of why I started work on libpwdb. But alas, a lack of time and > the widespread acceptance of nss which had an industry standard (from > Sun) to follow helped me abandon that project... > > What I've come to think I want to see is a 'credential caching daemon' - > let's call it 'pwdd' - that can be locally filled (by a PAM module, or > somesuch other 'trusted' application code), and which acts as an > in-memory super-set of the /etc/passwd and /etc/group files. Funny, this came up, I think on the PAM-KRB5 list as well. A generic credentials management system would indeed be nice -- there are so many kinds of credentials (e.g., NIS+ secrets, SSH keys, Kerberos TGTs, X.509 and other PKI certs, PGP keys, etc...). So far each system makes it's own credentials management system (e.g., ssh-agent, MIT ccaches, etc...). Even Windows has one, the Local Security Agent (LSA), which also takes care of Kerberos 'keytab' management, allowing non-priviledged apps to share a single Kerberos key with priviledged apps (this is done by exporting [a sub-set of] the SSPI (related to GSS-API) instead of the keytab). But I think this should be somewhat separate from a revamped NSS API. That one agent could provide an implementation of a creds mgmt and a name space access API is incidental. Apps then could use PAM (for initial auth), GSS-API (for network auth), both of which would seed the creds mgmt [agent] API which would then be available to the NSS API, also used by the apps. > There could be an nss_pwdd.so NSS handler (which would have a requisite > entry in /etc/nsswitch.conf) to provide the glibc:getpwnam() etc., > functionality for looking stuff up in 'pwdd's cache. But getpwnam() itself is just to 'fixed'. A flexible replacement is needed. > pam_*.so modules could seed 'pwdd' with transient entries for Kerberos > (or you name it) users, and a system bootup script (or even pwdd's own > configuration file), could initialize the cache with system users at > system boot. There would be some non-NSS interface to 'pwdd' for > adding/deleting/refreshing entries, and PAM modules could be just one of > the ways in which such functions get invoked. IPC locking mechanisms > within pwdd could make update/modification of data reliably atomic on > any given system. Also, better kernel creds 'passing' APIs are needed. And, I'll argue here as well, that Un*x systems need to have flexible, extensible kernel creds systems (here I'm referring to UIDs/GIDs/SIDs, not Kerberos tickets). Kernels need to have support for per-process creds arrays, and per-thread current-cred pointers. Kernel creds should support multiple cred types (e.g., Posix UIDs/GIDs, Windows SIDs, and whatever else comes along). ... > Its easy for me to suggest this - I don't plan to do any work on it! But > given this long exchange, I thought I would at least air this idea. > Perhaps someone has already created such a beast? Heh. Same here. As I said, several systems out there implement some of the above (e.g., ssh-agent, Kerberos, Samba's windbind, Solaris' nscd). Noone has put it all together, yet. > Cheers > > Andrew > Cheers, Nico -- . -DISCLAIMER: an automatically appended disclaimer may follow. By posting- -to a public e-mail mailing list I hereby grant permission to distribute- -and copy this message.- Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments.
