don't allow user to modify permissions on a folder they have created ACL SMB

[Johnny Fartpants]

Hi All,

I've recently stumbled across an issue that I have been blind to for many years and wondered if you were aware or better still any idea of how to fix it.

I have various SMB shares with my TrueNAS 13 connected to AD using AD groups to manage permissions. I would normally apply a couple of ACEs one for the AD group that needs modify access and a storage admin group to have full control. However when a member of the modify AD group creates a folder they have the ability to remove the storage admin ACE from the ACL which is not ideal. I have tried removing the 'change permissions' option but this does nothing and various other tweaks but it appears no matter what I do I can't stop this behaviour. It's essentially treating the person who created the folder as the owner allowing them to do whatever they want with permissions. I've gone through some old boxes I have running on version 11 and the same applies.

Anyway appreciate any thoughts you may have.

 

[Johnny Fartpants]

Sorted it. It was the share ACL that need changing from FULL to CHANGE. Hope this helps someone else out in the future.

 

[anodos]

Sorted it. It was the share ACL that need changing from FULL to CHANGE. Hope this helps someone else out in the future.

It's important to note that this is also an issue on Windows Server and MacOS servers. The owner of a file in general is super-user as to that file. Setting a share-level ACL sets an upper-bound on what can be done via the SMB protocol, but it does not change what can be done through other methods of accessing files (e.g. SSH).

 

[Johnny Fartpants]

It appears that if a filesystem ACE has 'modify' access but the share-level ACE is set to default which is 'FULL' then permissions on newly created folders can be modified via a Windows client. However if share-level ACE is set to 'CHANGE' this 'fixes' this behaviour no longer allowing permissions to be changed by members of that ACE. While in contrast an ACE on the filesystem with 'full control' maintains the ability to modify permissions via a Windows client regardless of if the share-level ACE is set to 'FULL' or "CHANGE'.

 

[anodos]

It appears that if a filesystem ACE has 'modify' access but the share-level ACE is set to default which is 'FULL' then permissions on newly created folders can be modified via a Windows client. However if share-level ACE is set to 'CHANGE' this 'fixes' this behaviour no longer allowing permissions to be changed by members of that ACE. While in contrast an ACE on the filesystem with 'full control' maintains the ability to modify permissions via a Windows client regardless of if the share-level ACE is set to 'FULL' or "CHANGE'.

If you create a directory, you own it and can change its permissions. Or are you saying you can do this for a directory owned by someone else?

 

[Johnny Fartpants]

Correct, Im talking about if you create it you have the ability to change its permissions. Problem is I find when creating multi-occupancy shares for 10s, 100s or even 1000s of users sooner or later one of them does something 'clever' causing massive issues. Therefore I like to prevent users from changing permissions. Naively perhaps I thought this was done via the ACEs on the filesystem making sure the 'change permissions' is not allowed. It appears that only applies to folders you did not create yourself. Setting the share-level ACL to 'CHANGE' does however give me the desired effect not allowing ACEs with 'modify' access from changing permissions but still allowing storage admins with 'full control' changing permissions.

Still not quite sure why 'full control' on an ACE on the filesystem seems to veto share-level ACL when set to 'CHANGE' but glad it does.

PS: I get the last bit now. Obviously 'full control' allows you to change permissions on folders created by other users hence why the share-level ACL doesn't really come into play.

 

[anodos]

Correct, Im talking about if you create it you have the ability to change its permissions. Problem is I find when creating multi-occupancy shares for 10s, 100s or even 1000s of users sooner or later one of them does something 'clever' causing massive issues. Therefore I like to prevent users from changing permissions. Naively perhaps I thought this was done via the ACE entry on the filesystem making sure the 'change permissions' is not allowed. It appears that only applies to folders you did not create yourself. Setting the share-level ACL to 'CHANGE' does however give me the desired effect not allowing ACE's with 'modify' from changing permissions but still allowing storage admins with 'full control' changing permissions.

Still not quite sure why 'full control' on an ACE on the filesystem seems to veto share-level ACL when set to 'CHANGE' but glad it does.

This is because of how the privilege system in Windows works. If this is AD, then Domain Admins are members have SeDiskOperatorPrivilege which allows complete override of all permissions. There are other privileges like this (SeBackupPrivilege / etc). The privilege system has been around since before NTFS - https://learn.microsoft.com/en-us/w...curity-policy-settings/user-rights-assignment

As I mentioned, you will need to do the same sort of thing with Windows servers. This is kind of how computers work. Equivalent of these privileges on Linux is CAP_DAC_OVERRIDE or generic CAP_SYS_ADMIN https://man7.org/linux/man-pages/man7/capabilities.7.html

For case of TrueNAS local users, I've made it so that members of the group builtin_administrators have the admin capabilities over SMB. Same sort of reasoning. If you give your user god-like access to the server, they can do god-like things.