Continuing the discussion from Users and Groups - How does the security work?:
Having spent the last few days working with a DL4100, I finally understand why I kept receiving “CIFS Password” log messages and Windows and OSX login errors.
The WD PHP/JS dashboard code for manipulating the smb.cnf file is NOT commutative. I.e., the order you assign users and grooups permissions to shares and the order you add and remove users from groups results in different settings in the smb.cnf file.
Specifically, the rules for samba/SMB are well described here “samba.org Chapter 9. Users and Security”.
My situation was that using the dashboard (wd web interface) I created a user “dtest”, that resulted in a share called “dtest”. I then created a group called “home”. I then added “dtest” to the group “home” and after some adds and removes of permissions to the “dtest” share, I was mysteriously denied access to the “dtest” share.
In truth I had this problem for many users and groups I had set up. The mystery was that the web dashboard showed that, in this case, user dtest had RW access to share dtest, while no other users or groups were granted permission, and dtest share had public access turned OFF.
In that configuration dtest should have been able to log in and connect to share dtest. I wasted days fiddling with network switches and windows smb/network related issues before testing with a OSX and linux machine (including numerous calls to WD support).
Once I tested with linux machines and OSX machines I readily verified the problem was not in the network, or on the clients. It was in fact in the WD NAS server itself. From there I enabled SSH and logged into the machine and examined the SMB configuration. What I saw in the smb.conf file explained very clearly what the problem was.
The WD web dashboard (which is a apache PHP/JS web app) had not commutatively (correctly) maintained the permissions in the smb.conf file.
The Samba rules state clearly that you can set the following list of rules:
valid users=, invalid users=, read list=, write list=.
Samba rules also detail use of @,&,+ for specifying NIS (smb perms) and HOST (linux ext4) perms ordering.
What WD NAS does is make all files and directories on the share drives 777 so owner, group, other all have RWX permissions. Thus access to shares is completely controlled by the NIS (smb) rules only. Because SMB perms are always based on requiring that BOTH NIS and HOST filesystem permission must be enabled for a user to have access. So, by using linux 777 (RWX for everyone), only the NIS (smb conf) rules need to be modified. So, while less secure, it is fast and easy to manage for the WD dashboard software tools.
With that in mind, the only question was why were the NIS rules not letting dtest have access to the dtest share when the WD dashboard said dtest had RW access.
The answer:
dtest was listed in the write list=, dtest was listed in the valid users= rules, @home was listed in the invalid users= rules, AND the BUG… dtest WAS NOT listed in the read list= rules.
Since invalid users trumps valid users, dtest was denied access based on being a member of the home group. So to provide WRITE access it needs write list= which trumps invalid users= so dtest had WRITE access. To provide READ access it needs read list= which also trumps invalid users=, BUT dtest was not in the read list= and thus DID NOT have READ access. Which by NIS SMB rules meant the user would be denied when attempting to log in.
What’s more confusing is that if the user was already authenticated to the share and had it mounted/mapped etc, and one then used the WD dashboard to add them to a group, the smb.conf file would be incorrectly set up as described above, but the user would still be able to access the share until their session needed to be reconnected. I.e., they were not forced to re-authenticate by the WD code configuring the SAMBA (SMB) permissions in the smb.conf tables because it thought (presumably) that the session would still have permission since the user had RW even though the group the user belonged to, did not.
The WD code needs to be revised to correctly (commutatively) preserve the NIS permissions in the smb.conf file without regard to the order in which a user, share, or group are manipulated to grant private Read or RW access. It should not matter in what order a user is granted, revoked, or a group is granted, revoked access to a share, or a user is added/removed from a share. BUT in fact it does matter and it gets incorrectly configured.
