What I think is happening: ====================== Perhaps I am missing something but it appears that userdel and usermod clean up /etc/passwd but leave junk entries in /var/etc/smbpasswd.
I think I understand how it happens: 1) I set up SMB sharing including issuing the infamous # echo "other password required pam_smb_passwd.so.1 nowarn" >> /etc/pam.conf 2) I useradd a few users and run passwd for each. The "other password..." tags on to the end of passwd's job the action of creating or updating an entry in /var/etc/smbpasswd. 3) I usermod or userdel some users. Since usermod and userdel have nothing to do with pam or pam.conf and haven't been configured for any follow-on behavior similar to "other password...", they blissfully do their work and ignore /var/smb/smbpasswd 4) Junk accumulates. I'm guessing the developers knew about this but figured no harm done as long as passwd keeps things up to date for existing users. However, the follow-on process doesn't always update the correct /var/smb/smbpasswd entry (in fact there may not BE a correct/consistent entry after userdels and usermods). The specific scenario I witnessed: ============================= My username was 'owen' with a UID of 101. I later added a user for testing with a username of 'Owen' and a UID of 105. After testing I wanted to use the username Owen myself so I: # userdel Owen # usermod -l Owen owen At this point my /etc/passwd file had an entry for 'Owen' with a UID of 101 and no user with UID 105. My /var/smb/smbpasswd, on the other hand, still had 'owen' with UID 101 and 'Owen' with UID 105. Next, to update smbpasswd: # passwd Owen In /etc/passwd, the new password was updated for user 'Owen' UID 101. However, in /var/smb/smbpasswd, it seems to have updated the user 'owen' with UID 101 and left the user 'Owen' with UID 105 alone. The result is that, when logging in to OpenSolaris locally, I can use the username 'Owen' with the new password and log in as UID 101. However, when I try to access the SMB share, the username 'Owen' is always denied access (presumably because it maps to UID 105 which is invalid as far as Solaris is concerned) but logging in as 'owen' works (even though that user doesn't exist from the OS's point of view). The bug? ======== passwd is looking up the entry to edit in /etc/passwd by name then looking up /var/smb/smbpasswd by UID and not ensuring the that the entries in the two files are consistent. Correct behavior would be to either: A) Perform the second lookup by name as well and update the UID of the entry if it does not match /etc/passwd. Also, delete any other entry that may already be using that UID. B) Perform the second lookup by UID but update username to match /etc/passwd. Again, delete conflicting entries if one already exists with the updated username. Essentially, if usermod and userdel don't clean up after themselves, passwd needs to anticipate the mess and pick up the slack. The workaround would be to manually edit /var/smb/smbpasswd to get rid of all conflicting/inconsistent entries and let passwd create new ones. While I'm at it, two other quirky behaviors I have encountered so far: - useradd with a username longer than 8 characters issues a dire-sounding error which makes one think the command was not successful. However, the user then exists and is perfectly functional (as far as I can tell.) Perhaps the error should have come across as a warning of some possible ramifications? - Autohome shares don't seem to care about the case of usernames. It appears they will always share a directory of lowercase(username). So users 'Owen' and 'owen' (with different UIDs) are served up the same home directory. Owen Davies -- This message posted from opensolaris.org _______________________________________________ storage-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/storage-discuss
