ewhac
Contributor
- Joined
- Aug 20, 2013
- Messages
- 177
I'm posting this partly as a log of my discoveries so far, and partly as a potentially helpful resource for other people who are having trouble getting their CIFS shares to work in the expected way. One of the things that prompted all this thrashing around was the fear that permissions/access controls were stored in more than one place, and that Bad Things happened if they got out of sync. However, from my experiments so far, it appears that FreeBSD/ZFS ACLs are used as the One True Source of file/directory access controls.
Corrections to this post are welcome and encouraged.
Observation The First: No One Uses Mode Bits Any More.
Mode bits are the semi-formal name given to the decades-old and extremely familiar rwx-style UNIX permission bits. There's just one problem:
The filesystem does not store mode bits any longer. Anything you see in the output of the
Each of the files above has an Access Control List (ACL) comprised of three Access Control Entries (ACEs). In this case, they are deemed "trivial" ACEs because they map directly to the old-style UNIX mode bits with no leftovers. The meanings of the various flags in the ACEs are documented in setfacl(1), and are summarized as follows:
Although ACLs are much more flexible (and confusing) than mode bits, there are a couple of things that don't translate. Chief among these are the various "sticky bits" and "setuid" bits, which can't be directly expressed in ACLs.
Observation The Second: Windows Will Do It Differently (And Wrong).
For UNIX/Linux users, it is natural to assume that, once you've created a directory/share,
Windows, however, is a petulant, needy little so-and-so, and regards that as insufficient. Note from the list above that, for the file's owner, mode 07xx translates to the owner ACE:
Once done, Windows will finally concede that you have Full Control over the file/directory/share. (And no, setfacl(1) is not a very friendly program.)
Observation The Third: Samba Translates FreeBSD/ZFS ACLs to Windows/CIFS ACLs and Back On The Fly
Some tutorials on setting setting/fixing CIFS permissions use the Samba tool
Note the first ACE in
However, if we set all the bits in the owner ACE, Samba will then show it as having full control:
Once again, Windows will now see the owner as having Full Control over the directory.
Observation The Fourth: Samba Will Do Whatever Is Most Appropriate for The Creating Client
Put differently: If you
On a day-to-day basis, you can still think in terms of the rwx-style mode bits, and use chmod(1) to change permissions on files. These will be converted into corresponding ACEs under the hood, and Samba will do the best it can to translate those for Windows, and many (most?) simple file operations will work across platforms. It's when you start getting in to the finer details of permissions and access control and Windows' peculiar expectations that the impedance mismatch starts to become noticeable, and you need to be aware of the details. Hopefully this discussion offered a bit more insight into what's going on, and maybe even how to fix it.
Corrections to this post are welcome and encouraged.
Observation The First: No One Uses Mode Bits Any More.
Mode bits are the semi-formal name given to the decades-old and extremely familiar rwx-style UNIX permission bits. There's just one problem:
Code:
freenas$ ls -alR testdir/ total 36 drwxr-xr-x 2 ewhac ewhac 8 Apr 24 12:29 . drwxr-xr-x+ 26 ewhac ewhac 74 Jul 10 14:18 .. -r--r--r-- 1 ewhac ewhac 0 Apr 21 00:09 R--R--R-- -r-xr-xr-x 1 ewhac ewhac 0 Apr 21 00:09 R-XR-XR-X -rw-r--r-- 1 ewhac ewhac 0 Apr 21 00:10 RW-R--R-- -rwx------ 1 ewhac ewhac 0 Apr 21 00:08 RWX------ -rwxr-xr-x 1 ewhac ewhac 0 Apr 21 00:08 RWXR-XR-X -rw-r--r-- 1 ewhac ewhac 0 Apr 24 12:29 whoami ^^^^^^^^^^ ||||||||||-- THIS IS A FLAT-OUT STINKING LIE!
The filesystem does not store mode bits any longer. Anything you see in the output of the
ls command is a synthetic reconstruction from the actual permission checking mechanism: ACLs.Code:
freenas$ getfacl testdir/* # file: testdir/R--R--R-- # owner: ewhac # group: ewhac owner@:r-----aARWcCos:-------:allow group@:r-----a-R-c--s:-------:allow everyone@:r-----a-R-c--s:-------:allow # file: testdir/R-XR-XR-X # owner: ewhac # group: ewhac owner@:r-x---aARWcCos:-------:allow group@:r-x---a-R-c--s:-------:allow everyone@:r-x---a-R-c--s:-------:allow # file: testdir/RW-R--R-- # owner: ewhac # group: ewhac owner@:rw-p--aARWcCos:-------:allow group@:r-----a-R-c--s:-------:allow everyone@:r-----a-R-c--s:-------:allow # file: testdir/RWX------ # owner: ewhac # group: ewhac owner@:rwxp--aARWcCos:-------:allow group@:------a-R-c--s:-------:allow everyone@:------a-R-c--s:-------:allow # file: testdir/RWXR-XR-X # owner: ewhac # group: ewhac owner@:rwxp--aARWcCos:-------:allow group@:r-x---a-R-c--s:-------:allow everyone@:r-x---a-R-c--s:-------:allow # file: testdir/whoami # owner: ewhac # group: ewhac owner@:rw-p--aARWcCos:-------:allow group@:r-----a-R-c--s:-------:allow everyone@:r-----a-R-c--s:-------:allow
Each of the files above has an Access Control List (ACL) comprised of three Access Control Entries (ACEs). In this case, they are deemed "trivial" ACEs because they map directly to the old-style UNIX mode bits with no leftovers. The meanings of the various flags in the ACEs are documented in setfacl(1), and are summarized as follows:
- r: read_data
- w: write_data
- x: execute
- p: append_data
- D: delete_child
- d: delete
- a: read_attributes
- A: write_attributes
- R: read_xattr
- W: write_xattr
- c: read_acl
- C: write_acl
- o: write_owner
- s: synchronize
Although ACLs are much more flexible (and confusing) than mode bits, there are a couple of things that don't translate. Chief among these are the various "sticky bits" and "setuid" bits, which can't be directly expressed in ACLs.
Observation The Second: Windows Will Do It Differently (And Wrong).
For UNIX/Linux users, it is natural to assume that, once you've created a directory/share,
chowned its owner and group IDs to you, and set the mode bits to 0755, you're done. You can create, modify, and delete your own files; and other FreeNAS users can view, but not modify, your files. If you don't want other users snooping at all, set the mode bits to 0700, and you're done.Windows, however, is a petulant, needy little so-and-so, and regards that as insufficient. Note from the list above that, for the file's owner, mode 07xx translates to the owner ACE:
owner@:rwxp--aARWcCos:-------:allow. In particular the d and D bits are not set. For Windows to be satisfied that you have "full control" over the file/share, all the ACL flags must be set. And while most tutorials tell you to do this from within Windows, you can in fact do it using setfacl(1) by creating a new ACE with all the bits set and deleting the old one:Code:
freenas$ ls -dl testdir/DRWXR-XR-X drwxr-xr-x 2 ewhac ewhac 2 Jul 11 00:36 testdir/DRWXR-XR-X freenas$ getfacl testdir/DRWXR-XR-X # file: testdir/DRWXR-XR-X # owner: ewhac # group: ewhac owner@:rwxp--aARWcCos:-------:allow group@:r-x---a-R-c--s:-------:allow everyone@:r-x---a-R-c--s:-------:allow freenas$ setfacl -a 0 owner@:full_set:-------:allow testdir/DRWXR-XR-X freenas$ getfacl testdir/DRWXR-XR-X # file: testdir/DRWXR-XR-X # owner: ewhac # group: ewhac owner@:rwxpDdaARWcCos:-------:allow owner@:rwxp--aARWcCos:-------:allow group@:r-x---a-R-c--s:-------:allow everyone@:r-x---a-R-c--s:-------:allow freenas$ setfacl -x 1 testdir/DRWXR-XR-X freenas$ getfacl testdir/DRWXR-XR-X # file: testdir/DRWXR-XR-X # owner: ewhac # group: ewhac owner@:rwxpDdaARWcCos:-------:allow group@:r-x---a-R-c--s:-------:allow everyone@:r-x---a-R-c--s:-------:allow
Once done, Windows will finally concede that you have Full Control over the file/directory/share. (And no, setfacl(1) is not a very friendly program.)
Observation The Third: Samba Translates FreeBSD/ZFS ACLs to Windows/CIFS ACLs and Back On The Fly
Some tutorials on setting setting/fixing CIFS permissions use the Samba tool
smbcacls (which is even more cumbersome that setfacl(1)). My experiments strongly suggest that Samba is using the underlying ZFS ACLs directly and translating them to Windows/CIFS. Using a freshly re-created example directory:Code:
freenas$ mkdir testdir/DRWXR-XR-X freenas$ ls -dl testdir/DRWXR-XR-X drwxr-xr-x 2 ewhac ewhac 2 Jul 11 01:20 testdir/DRWXR-XR-X [ewhac@alexandria ~]$ getfacl testdir/DRWXR-XR-X # file: testdir/DRWXR-XR-X # owner: ewhac # group: ewhac owner@:rwxp--aARWcCos:-------:allow group@:r-x---a-R-c--s:-------:allow everyone@:r-x---a-R-c--s:-------:allow freenas$ smbcacls //alexandria/ewhac testdir/DRWXR-XR-X Enter WORKGROUP\ewhac's password: REVISION:1 CONTROL:SR|DP OWNER:ALEXANDRIA\ewhac GROUP:S-1-5-21-135190865-3541278195-1833594169-1000 ACL:ALEXANDRIA\ewhac:ALLOWED/0x0/0x001e01ff ACL:S-1-5-21-135190865-3541278195-1833594169-1000:ALLOWED/0x0/READ ACL:Everyone:ALLOWED/0x0/READ
Note the first ACE in
smbcacls' output: ACL:ALEXANDRIA\ewhac:ALLOWED/0x0/0x001e01ff. Normally, that last component after "ALLOWED/0x0/" should be "READ", "CHANGE", or "FULL". Instead we have a hexadecimal constant which presumably represents the "everything except d and D" ACL permission bits.However, if we set all the bits in the owner ACE, Samba will then show it as having full control:
Code:
freenas$ setfacl -a 0 owner@:full_set::allow testdir/DRWXR-XR-X freenas$ setfacl -x 1 testdir/DRWXR-XR-X freenas$ getfacl testdir/DRWXR-XR-X # file: testdir/DRWXR-XR-X # owner: ewhac # group: ewhac owner@:rwxpDdaARWcCos:-------:allow group@:r-x---a-R-c--s:-------:allow everyone@:r-x---a-R-c--s:-------:allow [ewhac@alexandria ~]$ smbcacls //alexandria/ewhac testdir/DRWXR-XR-X Enter WORKGROUP\ewhac's password: REVISION:1 CONTROL:SR|DP OWNER:ALEXANDRIA\ewhac GROUP:S-1-5-21-135190865-3541278195-1833594169-1000 ACL:ALEXANDRIA\ewhac:ALLOWED/0x0/FULL ACL:S-1-5-21-135190865-3541278195-1833594169-1000:ALLOWED/0x0/READ ACL:Everyone:ALLOWED/0x0/READ
Once again, Windows will now see the owner as having Full Control over the directory.
Observation The Fourth: Samba Will Do Whatever Is Most Appropriate for The Creating Client
Put differently: If you
mkdir from a Linux client, you'll get a directory with the three trivial ACEs that represent your user's default umask/mode bits (frequently 0755). If, however, you create a new folder from a Windows client, you'll get a directory with a set of default ACEs that Windows deems appropriate. Exactly what these ACEs are will depend on your user privileges on the share, and which ACLs if any are inherited from the parent directory. (Oh, yeah. ACLs are inheritable. That's another topic entirely.)On a day-to-day basis, you can still think in terms of the rwx-style mode bits, and use chmod(1) to change permissions on files. These will be converted into corresponding ACEs under the hood, and Samba will do the best it can to translate those for Windows, and many (most?) simple file operations will work across platforms. It's when you start getting in to the finer details of permissions and access control and Windows' peculiar expectations that the impedance mismatch starts to become noticeable, and you need to be aware of the details. Hopefully this discussion offered a bit more insight into what's going on, and maybe even how to fix it.
