Only passwd will have an effect on /var/smb/smbpasswd. useradd,
userdel and usermod should have no effect on /var/smb/smbpasswd.
Yes, you can play around with the user commands and end up with
/var/smb/smbpasswd being out of step with /etc/passwd. However,
given that Windows account names are case-insensitive, if you are
sharing files over CIFS and creating account names that differ only
by case, it seems likely to be confusing and problematic for those
accessing the system via CIFS.
>> - useradd with a username longer than 8 characters issues a
>> dire-sounding error which makes one think the command was not
>> successful.
# useradd qwertyuiopasdfghjkl
UX: useradd: qwertyuiopasdfghjkl name too long.
This is a warning that the name is too long. Did you see something
else?
>> - 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.
This is by design because Windows account names are case-insensitive,
and it shouldn't cause a problem. Consider the situation when both
owen and Owen are connected and try to access each other's home
directory shares. Whether or not they gain access to the directory
depends on the directory ownership and permissions, not whether or
not the directory is shared.
Alan
--
Jeff Cheeney wrote:
> Owen, thanks for taking the time to write up your issues. I'm CC'ing the
> cifs-discuss list on my reply so the experts can see your issues. Also,
> would you mind filing bugs at http://bugs.opensolaris.org/?
>
>
> --jc
>
> ---
> Jeff Cheeney | OpenSolaris Storage Community |
> http://opensolaris.org/os/storage | http://blogs.sun.com/icedawn
>
>
> On 09/01/08 21:44, Owen Davies wrote:
>> 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
>>
>
> _______________________________________________
> cifs-discuss mailing list
> [EMAIL PROTECTED]
> http://mail.opensolaris.org/mailman/listinfo/cifs-discuss
_______________________________________________
storage-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/storage-discuss
