Description of problem: chage -l does not allow listing, and chage -d (etc.) does not allow editing, of users in /etc/shadow but not in /etc/passwd. Why would we want such a silly thing? Because we don't want usernames trivially listable in /etc/passwd, and some things (especially password aging) don't work in some applications unless users are in /etc/shadow. Version-Release number of selected component (if applicable): shadow-utils-4.0.3-20 How reproducible: Always Steps to Reproduce: 1. In /etc/nsswitch.conf, set passwd to "db nis ldap files" or somesuch, but leave shadow at "files." 2. Leave user joeschmo defined in /etc/shadow, but remove from local /etc/passwd 3. chage -l joeschmo Actual Results: chage: unknown user: joeschmo Expected Results: Minimum: 0 Maximum: 99999 Warning: 30 Inactive: 30 Last Change: Jan 05, 2004 Password Expires: Never Password Inactive: Never Account Expires: Never Additional info: Since it is legal to have nsswitch point passwd and shadow at different things, chage should use getpwnam() instead of parsing /etc/passwd directly. On our shell servers, we have users defined in /var/db, and a library called in /etc/ld.so.preload disables stepping through passwd file entries thusly: #include <stdio.h> char * getpwent(void) { return NULL; } Yeah, anyone who knows how to read a db file can still get the list of users from the world-readable db, but this slows the potential undergraduate spammers down a little.
I would recommend against doing this -- the files read by nss_db are meant to be used to speed lookups of the flat files in /etc, not as an alternate source of information like NIS. The Makefile in /var/db re-creates the files which reside there using the contents of the files in /etc, which if emptied, would produce empty database files. The contents of all of the readable data sources can also be trivially read using libc functions or the command-line "getent" program. I guess what I'm saying is that you don't really gain anything by what you're outlining above, and actually risk losing account information. Marking wontfix.
I accept that what we're doing is wacked, but I'd still call this a (low priority) bug. Forget nss_db (which was removed from RHEL3 in any case). What about people using NIS or LDAP to append users to /etc/passwd? Kerberos doesn't provide all of the functionality of /etc/shadow. It's possible that sane people might want to use Kerberos for authentication, but /etc/shadow for account locking/expiration.