Overambitious Overview of CIFS Permissions

[anodos]

Apologies, I'm being a bit lazy by composing this in my browser rather than writing it in a text editor and posting once complete. Please chime in and correct me where I am wrong on the below points.

Correctly setting permissions requires care and planning. Samba offers several points of control for permissions. While this is extremely useful for experienced admins, the flexibility of samba access controls trips up new users. In this post I will cover the basic points of control for CIFS permissions and give an example of a fairly simple working CIFS configuration. I am writing this with the following caveat: I am not an IT professional and I am doing this for free. When you get things for free... well... let's just say you sometimes get what you pay for. In (1) I will cover points of control for file system access management, in (2) I will outline a general strategy for creating a CIFs configuration that is easy to troubleshoot, in (3) I will give an example CIFs configuration, in (4) I will list my sources.

(1) Points of control for file system access management
Samba offers four primary access control facilities: (a) unix file and directory permissions, (b) samba share definitions, (c) NT Share Permissions, and (d) ACLs. New users tend to take a shotgun approach to setting up access controls, by tweaking almost all of the above. This makes problems very difficult to troubleshoot and almost always results in permissions being "broken".

(1a) Unix File and Directory Permissions
The short version of this for is "these are not the permissions you are looking for". By default samba on FreeNAS is configured to use ZFS ACLs. Modifying these from the CLI can break permissions on shares.


(1b) Samba Share Definitions
In some situations it is necessary to force all users to write to a share as if a single user were doing so. In other situations it is necessary to enforce a high level of paranoia about access controls and explicitly define which users and groups can read or write to a share. For a complete overview of the ones relevant to user and group permissions, refer to the following entries in the smb.conf manpage: admin users, force group, force user, guest ok, invalid users, valid users, and write list.

There are edge cases where you may need to use these. You will probably know it when you are in this situation. When in doubt, use (1d) to set access controls on your samba share.

(1c) NT Share Permissions
By default, Samba sets no restrictions on the share itself and it does not provide a tool for the configuring the share's access controls. Samba stores the per-share access control settings in a file called share_info.tdb.

For instructions on how to set these on a FreeNAS server, see here: https://forums.freenas.org/index.php?threads/cifs-tips-and-tricks.34995/#post-241346

(1d) ACLS
These are the recommended way of manipulating permissions. See post here: https://forums.freenas.org/index.ph...-of-how-to-configure-share-permissions.35276/

(2) Making Your Access Controls Troubleshooting Friendly
Having the above points of control for managing permissions in samba does not mean one should use them all at once. The best strategy for making your permissions easy to troubleshoot and likely to work the first go-around is to follow the below tips:

• Sit down with a pen and paper. Draw out your file tree and group together parts of it based on which users and groups need access to the files located there.

• Create groups based on your design (be sure to include one for samba admins)

• Create a datasets for your shares and have them owned by your samba admin group.

• Set ACL type to Windows (unless you have a specific reason not to set them that way).

• Do all configuration through the FreeNAS GUI or through Windows Explorer.

• Do not apply Samba the tweaks your read about on blogs to make samba 'get more fasterer'.

• Avoid complexity. Lots of shares with permissions defined at the share level is a better design than few shares with chaotic/complex ACLs inside them.

(3) Example Samba Configuration
[Will add text here when I feel like it]

(4) Sources
https://www.samba.org/samba/docs/man/Samba-HOWTO-Collection/AccessControls.html
http://www.freebsd.org/doc/handbook/permissions.html
http://www.freebsd.org/doc/handbook/network-samba.html
http://windows.microsoft.com/en-us/windows/what-are-permissions#1TC=windows-7
http://technet.microsoft.com/en-us/library/bb727008.aspx

 

[cyberjock]

I don't want to slam your hard work, but I've got a task to write a guide for doing permissions properly. To boot, permissions in the 9.2.1.x series behave differently than 9.2.0(and prior) and even pre-9.2.1.6. Even the currently nightlies aren't completely setup properly from what I gather. So I'm not sure how you are going to provide advice on a topic that is still "in progress". ;)

 

[AaronLS]

"Note: If you take away all permissions from the Everyone user without removing this user, effectively no user will be able to access the share. This is a result of what is known as ACL precedence. Everyone with no access means that MaryK who is part of the group Everyone will have no access even if she is given explicit full control access."

Are you referring to removing the Allow permission from Everyone, as opposed to setting a Deny permission? Because in native Windows all Allow permissions are cumulative such that as long as you have an allow in at least the user and/or group you belong to, you will have access. Only Deny permissions are capable of overriding those. So unless the behavior is different for CIFS, I would reword to refer to "Deny permissions" taking precendance. Simply removing the Allow permissions should not cause a denial so long as the user still has an Allow. Granted, I do not understand all the ways CIFS supports Windows permissions, so if this is a nuance of that please forgive my comment.

 

[anodos]

... in native Windows all Allow permissions are cumulative such that as long as you have an allow in at least the user and/or group you belong to, you will have access. Only Deny permissions are capable of overriding those.

AaronLS, you are correct. This illustrates why one shouldn't copy and paste documentation without verifying things for oneself. :)