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. 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. 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. The 'read-only' stuff that regular programs like 'ls' and 'id' do all the time would simply read the in-memory cache via the nss_pwdd.so module, and wouldn't need to link to PAM or anything besides glibc to get their job done. 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? Cheers Andrew
