Is aclmode = restricted actually needed for Samba shares?

[anodos]

Some people play video games for entertainment. Some people feed pigeons for entertainment. What I'm doing here is more of the latter than the former.

Out of an abundance of pedantry, I want to try to document what goes wrong when we chmod a directory / file with ACLs.

Take an example of a complex ACL on a file:

Code:

[root@rivendell] ~# getfacl /mnt/Tank/farts/
# file: /mnt/Tank/farts
# owner: root
# group: wheel
	 owner@:rwxpDdaARWcCos:-----:allow
	 group@:rwxpDdaARWcCos:-----:allow
group:DOMAIN\Minions:r-x---a-R-c---:-----:allow
group:DOMAIN\Domain Admins:rwxpDdaARWcCos:-----:allow

Then chmod 770 /mnt/Tank/farts

Code:

[root@rivendell] ~# getfacl /mnt/Tank/farts/
# file: /mnt/Tank/farts
# owner: root
# group: wheel
	 owner@:rwxp--aARWcCos:-----:allow
	 group@:rwxp--a-R-c--s:-----:allow
  everyone@:------a-R-c--s:-----:allow
group:DOMAIN\Minions:r-x---a-R-c---:-----:allow
group:DOMAIN\Domain Admins:rwxpDdaARWcCos:-----:allow

Have my ACLs been borked? Not really. The aces I really care about are still there:

Code:

group:DOMAIN\Minions:r-x---a-R-c---:-----:allow
group:DOMAIN\Domain Admins:rwxpDdaARWcCos:-----:allow

In addition to this, what permissions are missing?
owner@ is missing "Dd", but (w) implies "Dd" so nothing is lost.
group@ is missing "ARC". The owner group can write and delete, but lacks the ability to modify permissions, xattrs, and attributes. Something is lost, but not a lot.

Users have to adjust their create / directory masks, but I wouldn't say that permissions are totally borken. In fact, if users are managing samba shares through explicit ACES (i.e group:DOMAIN\Domain Admins:rwxpDdaARWcCos:-----:allow) it seems like they aren't effected at all by chmod operations.

So... does anyone have a reproducible example of ZOMG ACLs are borken! :D

 

[anodos]

This old git commit shows some behavior that I've seen before in the past.

Code:

With NFSv4 ACLs, it is possible that applying a mode to an ACL which

is identical to the mode computed from that ACL will modify the ACL.
For example, mode computed from the following ACL is 0600:

   user:kamila:rwx--------C--:------:allow
		owner@:--x-----------:------:deny
		owner@:rw-p---A-W-Co-:------:allow
		group@:rwxp----------:------:deny
		group@:--------------:------:allow
	 everyone@:rwxp---A-W-Co-:------:deny
	 everyone@:------a-R-c--s:------:allow

However, applying that mode (chmod 0600) changes the ACL into this:

   user:kamila:rwx-----------:------:deny
   user:kamila:rwx--------C--:------:allow
		owner@:--x-----------:------:deny
		owner@:rw-p---A-W-Co-:------:allow
		group@:rwxp----------:------:deny
		group@:--------------:------:allow
	 everyone@:rwxp---A-W-Co-:------:deny
	 everyone@:------a-R-c--s:------:allow

In chmod(1) utility, there is an optimisation, which makes it not
call chmod(2) if the mode of the file is the same as the new mode.
Disable that optimisation for files which may have NFSv4 ACLs.

This is of course fixed, but looks pretty terrible. It at least gives an idea about what can go wrong and how to fix it.

 

[anodos]

Let's look a bit closer at how chmod actually affects inheriting ACLs.

Code:

[root@rivendell] ~# getfacl /mnt/Tank/farts/
# file: /mnt/Tank/farts
# owner: root
# group: wheel
	 owner@:rwxpDdaARWcCos:fd----:allow
	 group@:rwxpDdaARWcCos:fd----:allow
group:DOMAIN\Minions:r-x---a-R-c---:fd---:allow
group:DOMAIN\Domain Admins:rwxpDdaARWcCos:fd---:allow

With the above ACL, if I create a file via the CLI, the inheritance flags on the ACLs representing the Unix mode bits will determine the mode of the newly created file.
touch /mnt/Tank/farts/pile

Code:

[root@rivendell] ~# getfacl /mnt/Tank/farts/pile
# file: /mnt/Tank/farts/pile
# owner: root
# group: wheel
	 owner@:rwxpDdaARWcCos:fd---I:allow
	 group@:rwxpDdaARWcCos:fd---I:allow
group:DOMAIN\Minions:r-x---a-R-c--I:fd---:allow
group:DOMAIN\Domain Admins:rwxpDdaARWcCos:fd--I:allow

The "I" flag at the end of the ACE indicates that it was inherited. What happens if I run chmod 770 /mnt/Tank/farts before creating the file? Now my ACLs look like this

Code:

[root@rivendell] ~# getfacl /mnt/Tank/farts/
# file: /mnt/Tank/farts
# owner: root
# group: wheel
	 owner@:rwxp--aARWcCos:-----:allow
	 group@:rwxp--a-R-c--s:-----:allow
everyone@:------a-R-c--s:-----:allow
group:DOMAIN\Minions:r-x---a-R-c---:fd---:allow
group:DOMAIN\Domain Admins:rwxpDdaARWcCos:fd---:allow

Note the lack of "fd" inheritance flags on the newly minted ACEs representing the Unix mode bits I set via chmod. Now let's create a file touch /mnt/Tank/farts/pile.

Code:

[root@rivendell] ~# getfacl /mnt/Tank/farts/pile
# file: /mnt/Tank/farts/pile
# owner: root
# group: wheel
	 owner@:rw-p--aARWcCos:-----:allow
	 group@:r-----a-R-c--s:-----:allow
everyone@:r-----a-R-c--s:-----:allow
group:DOMAIN\Minions:r-x---a-R-c---:fd---:allow
group:DOMAIN\Domain Admins:rwxpDdaARWcCos:fd---:allow

Explicit ACEs continue to be inherited properly, but the special ACEs are set according to the umask. The same applies to files / folders created by samba. They will inherit special ACEs if the ACEs have the inheritance flags set. If they are not set, then the values of owner@, group@, and everyone@ will be set according to the create mask and directory mask parameters.

 

[anodos]

Okay. Got my first interesting result. :D

Code:

[root@rivendell] /mnt/Tank/CaseInsensitive# getfacl goats
# file: goats
# owner: root
# group: DOMAIN\domain admins
group:DOMAIN\minions:r-----a-R-c---:fd----I:allow
group:DOMAIN\domain admins:rwxpDdaARWcCos:fd----I:allow
			owner@:rwxpDdaARWcCos:fd----I:allow
			group@:rwxpDdaARWcCos:fd----I:allow
		 everyone@:r-x---a-R-c---:fd----I:allow

Then chmod 474 goats

Code:

[root@rivendell] /mnt/Tank/CaseInsensitive# getfacl goats/
# file: goats/
# owner: root
# group: DOMAIN\domain admins
			owner@:-wxp----------:-------:deny
group:DOMAIN\minions:r-----a-R-c---:fd----I:allow
group:DOMAIN\domain admins:rwxpDdaARWcCos:fd----I:allow
			owner@:r-----aARWcCos:-------:allow
			group@:rwxp--a-R-c--s:-------:allow
		 everyone@:r-----a-R-c--s:-------:allow
[root@rivendell] /mnt/Tank/CaseInsensitive#

Boom! instead of just ending up with owner@:r-----aARWcCos:-------:allow I got a new ACE as a bonus owner@:-wxp----------:-------:deny.

 

[anodos]

Now what's wrong with the above permissions? Well, deny aces get priority over allow aces. In the following ACL, the owner, even if he's a member of Domain Admins, will be denied write and execute privileges to the folder

Code:

[root@rivendell] /mnt/Tank/CaseInsensitive# getfacl goats/
# file: goats/
# owner: root
# group: DOMAIN\domain admins
			owner@:-wxp----------:-------:deny
group:DOMAIN\minions:r-----a-R-c---:fd----I:allow
group:DOMAIN\domain admins:rwxpDdaARWcCos:fd----I:allow
			owner@:r-----aARWcCos:-------:allow
			group@:rwxp--a-R-c--s:-------:allow
		 everyone@:r-----a-R-c--s:-------:allow
[root@rivendell] /mnt/Tank/CaseInsensitive#

The expected result from chmod 474 was as follows:

Code:

[root@rivendell] /mnt/Tank/CaseInsensitive# getfacl goats/
# file: goats/
# owner: root
# group: DOMAIN\domain admins
 group:DOMAIN\minions:r-----a-R-c---:fd----I:allow
group:DOMAIN\domain admins:rwxpDdaARWcCos:fd----I:allow
			owner@:r-----aARWcCos:-------:allow
			group@:rwxp--a-R-c--s:-------:allow
		 everyone@:r-----a-R-c--s:-------:allow
[root@rivendell] /mnt/Tank/CaseInsensitive#

Domain Admins can still write to the folder.

 

[anodos]

Another example of how to screw things up
setfacl -x owner@::allow goats

Code:

[root@rivendell] /mnt/Tank/CaseInsensitive# getfacl goats/
# file: goats/
# owner: root
# group: DOMAIN\domain admins
group:DOMAIN\minions:r-----a-R-c---:fd----I:allow
group:DOMAIN\domain admins:rwxpDdaARWcCos:fd----I:allow
			group@:rwxp--a-R-c--s:-------:allow
		 everyone@:r-----a-R-c--s:-------:allow
[root@rivendell] /mnt/Tank/CaseInsensitive#

chmod o+r goats

Code:

[root@rivendell] /mnt/Tank/CaseInsensitive# getfacl goats/
# file: goats/
# owner: root
# group: DOMAIN\domain admins
			owner@:-w-p----------:-------:deny
group:DOMAIN\minions:r-----a-R-c---:fd----I:allow
group:DOMAIN\domain admins:rwxpDdaARWcCos:fd----I:allow
			owner@:r-x---aARWcCos:-------:allow
			group@:rwxp--a-R-c--s:-------:allow
		 everyone@:r-----a-R-c--s:-------:allow
[root@rivendell] /mnt/Tank/CaseInsensitive#

Nuking the owner@ ACE, then duplicating the read bit on "other" results in a deny ACE being written on my goats. I can no longer write to goats.

 

[anodos]

As you think about it, this makes sense. everyone@ is not identical to other in mode bits. This is because everyone@ includes everyone (including the file's owner and group). In some situations setting deny ACEs on owner@ and group@ is the only way to restrict the permissions granted by everyone@ (for instance, if you chmod 447 a file).

The problem is that chmod is inconsistent with when it adds deny ACEs. If I remove the Domain Admins ACE from above

Code:

[root@rivendell] /mnt/Tank/CaseInsensitive# getfacl goats/
# file: goats/
# owner: root
# group: DOMAIN\domain admins
group:DOMAIN\minions:r-----a-R-c---:fd----I:allow
			owner@:r-x---aARWcCos:-------:allow
			group@:rwxp--a-R-c--s:-------:allow
		 everyone@:r-----a-R-c--s:-------:allow

then chmod o-r goats. I get the following:

Code:

[root@rivendell] /mnt/Tank/CaseInsensitive# getfacl goats/
# file: goats/
# owner: root
# group: DOMAIN\domain admins
group:DOMAIN\minions:r-----a-R-c---:fd----I:allow
			owner@:r-x---aARWcCos:-------:allow
			group@:rwxp--a-R-c--s:-------:allow
		 everyone@:------a-R-c--s:-------:allow

So chmod is clearly freaking out when an explicit ACE exists that grants permissions to the owner-group of the file.