Samba Permissions

[Polly]

Hi,

I have just started testing FreeNAS (9.10.1-U2) and discovered some strange issues when using Samba and Windows ACL. I have create a share named "Share01" and in this share I have a folder named "Folder01". What I want is to have a admin user with full access permissions to everything under this folder and a group that is able to read/write.

Example:
Administrator: Admin01
Group(read/write): TestGroup01 (containing 1 user "User01")

Admin01: Full Control to this folder, subfolders and files
TestGroup01: All permissions WITHOUT change/modify permissions and take ownership on this folder, subfolders and files.

What happens when User01 (in group TestGroup01) creates a folder under Folder01 is that the group/admin permissions are remove and left is only the "User01" with full control meaning the user could also change permissions (big security issue). The only way I am able to get the correct permissions is by enabling the "acl_xattr" VFS object on the share but I think this should not be needed because of the native NTFSV4 support in FreeNAS.

Anyone know why this is happening? A bug?

 

[Ericloewe]

Have you seen @m0nkey_ 's SMB permissions videos?

 

[Polly]

Thank you Ericloewe, I have watched the videos and they are great but only explain basic permissions. I still have something strange happening with my ACL:s, and as I previously stated my permissions work as expected if I enable the VFS object "acl_xattr". Please see the screenshots.

Dataset permissions

Root folder permissions of Admin01

Root folder permissions of TestGroup01 (TestUser01 is member and have access)

Root folder permissions overview

This is what the permissions looks like after TestUser01 creates a new folder.
Admin got removed, TestGroup got removed...and TestUser01 have full control (!?)

 

[anodos]

Thank you Ericloewe, I have watched the videos and they are great but only explain basic permissions. I still have something strange happening with my ACL:s, and as I previously stated my permissions work as expected if I enable the VFS object "acl_xattr". Please see the screenshots.

Dataset permissions

View attachment 14537

Root folder permissions of Admin01

View attachment 14538

Root folder permissions of TestGroup01 (TestUser01 is member and have access)

View attachment 14539

Root folder permissions overview

View attachment 14540

This is what the permissions looks like after TestUser01 creates a new folder.
Admin got removed, TestGroup got removed...and TestUser01 have full control (!?)

View attachment 14541

I believe that's because of a subtle difference NFSv4 ACLs and NTFS ACLs. The default permissions on a share are like this:

Code:

[root@rivendell] ~# getfacl /mnt/Tank/TestShare/
# file: /mnt/Tank/TestShare/
# owner: admin
# group: wheel
	 owner@:rwxpDdaARWcCos:fd-----:allow
	 group@:rwxpDdaARWcCos:fd-----:allow
  everyone@:r-x---a-R-c---:fd-----:allow

This means that if some method creates a file /mnt/Tank/TestShare/foo.txt and then changes the file's owner to user1, the resulting ACL on foo.txt will look like this:

Code:

[root@rivendell] ~# getfacl /mnt/Tank/TestShare/foo.txt
# file: /mnt/Tank/TestShare/foo.txt
# owner: user1
# group: wheel
	 owner@:rwxpDdaARWcCos:fd-----:allow
	 group@:rwxpDdaARWcCos:fd-----:allow
  everyone@:r-x---a-R-c---:fd-----:allow

Note that the permissions for the owner@ Special ACE haven't changed. but "admin" has lost access. This is why I prefer to avoid using the Special ACE's for anything other than granting owner(user) and owner(group) a default level of access. Instead, you should add explicit ACEs for the groups you want to grant access to.

Your share's ACL from the CLI should look something like this instead:

Code:

[root@rivendell] ~# getfacl /mnt/Tank/TestShare/
# file: /mnt/Tank/TestShare/
# 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

I believe acl_xattr is able to safely sidestep issues with owner@, group@, and everyone@ because it doesn't have to interact with other unix processes.

 

[Polly]

I believe that's because of a subtle difference NFSv4 ACLs and NTFS ACLs. The default permissions on a share are like this:

Code:

[root@rivendell] ~# getfacl /mnt/Tank/TestShare/
# file: /mnt/Tank/TestShare/
# owner: admin
# group: wheel
	 owner@:rwxpDdaARWcCos:fd-----:allow
	 group@:rwxpDdaARWcCos:fd-----:allow
  everyone@:r-x---a-R-c---:fd-----:allow

This means that if some method creates a file /mnt/Tank/TestShare/foo.txt and then changes the file's owner to user1, the resulting ACL on foo.txt will look like this:

Code:

[root@rivendell] ~# getfacl /mnt/Tank/TestShare/foo.txt
# file: /mnt/Tank/TestShare/foo.txt
# owner: user1
# group: wheel
	 owner@:rwxpDdaARWcCos:fd-----:allow
	 group@:rwxpDdaARWcCos:fd-----:allow
  everyone@:r-x---a-R-c---:fd-----:allow

Note that the permissions for the owner@ Special ACE haven't changed. but "admin" has lost access. This is why I prefer to avoid using the Special ACE's for anything other than granting owner(user) and owner(group) a default level of access. Instead, you should add explicit ACEs for the groups you want to grant access to.

Your share's ACL from the CLI should look something like this instead:

Code:

[root@rivendell] ~# getfacl /mnt/Tank/TestShare/
# file: /mnt/Tank/TestShare/
# 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

I believe acl_xattr is able to safely sidestep issues with owner@, group@, and everyone@ because it doesn't have to interact with other unix processes.

Hi Anodos!

Thank you very much for you help.
I have given days to investigate this and came to pretty much the same conclusion as you did.
What I did was to create admin groups that where inherited from the root folder and now everything works just as expected even without the acl_xattr.

Thank you!