setfacl confusion

[Fab Sidoli]

Hi All,

I'm trying to get my head around the behaviour of ACLs in 11.3.

I have a dataset with the following ACLs

root # getfacl /mnt/store/home/fs
# file: /mnt/store/home/fs
# owner: fs
# group: sysgrp
owner@:rwxp--aARWcCos:-------:allow
group@:------a-R-c--s:-------:allow
everyone@:------a-R-c--s:-------:allow

In the BUI, if I add a user and give it full control I need to set Inheritance otherwise it won't let me add the ACL, despite the fact that none of the other options have inheritance enable. The CLI lets me do this. Anyway, out of curiosity, I do this in the BUI. Now the ALCs look like this.

root # getfacl /mnt/store/home/fs
# file: /mnt/store/home/fs
# owner: fs
# group: sysgrp
owner@:rwxp--aARWcCos:-------:allow
group@:------a-R-c--s:-------:allow
everyone@:------a-R-c--s:-------:allow
user:bacadm:rwxpDdaARWcCos:fd-----:allow
everyone@:--------------:fd-----:allow

I'm not sure I understand why the last ACL entry exists. Which presides? ACL 2 or 4 (note we start from 0 as far as setfacl is concerned). Via the CLI the new entry would actually appear at the top of this list, so user, owner@, group@, everyone@.

If I now try to remove the ACL I just added I can't because I'm told I need to have one inheritable ACL set.

From the command line, the following gets me back to where I started in both the BUI and CLI.

root # setfacl -x 4 /mnt/store/home/fs
root # setfacl -x 3 /mnt/store/home/fs

Questions:

1. How do the BUI and CLI relate? Does the BUI translate from the CLI and present a graphical representation?
2. What's the safest way to edit ACLs? The BUI or CLI (I'm most familiar with the latter).
3. I like the recursive feature of the BUI, show is achieved on the command line that doesn't involve an exec?
4. What is this extra everyone@ ACL actually for?

Thanks,
Fab

 

[anodos]

The UI will not let you set ACLs that lack inheriting entries. The reason for this is that if you set an ACL without inheritable ACEs, then new files and directories will end up with permissions of 000 (this is almost never intentional). The extra empty everyone@ entry is to make ACL behavior more correct on the windows-side. If an ACL lacks an inheritable special entry (owner@, group@, everyone@), then entries equivalent to the the current create / directory mask are added (which is almost never desired by SMB admins).

ACEs are reordered automatically into MS canonical order. If they are not reordered as such then the resulting ACL will cause an error message in the Windows ACL editor every time the ACL is viewed.

 

[Fab Sidoli]

Ah, I see. Thanks for clearing that up.

I have one other question if I may. I'd like to have an AD account that is effectively storage admin - i.e., has full access to all the data being exported. Under windows, however, if you give a user full control over their own directory there's nothing stopping them from removing the ACL in place for the storage admin. Is there a way of doing what I want here?

In the example above, bacadm is my storage admin and I would like it to have full access to all shares.

My storage pool looks like this

store/
store/group/
store/group/group1
etc..
store/home/
store/home/user1
etc...

Effectively, I'd like the storage admin account to have access from store down in a way that is immutable and is inherited all the way down the tree. Is this possible?

If I'm not making sense please let me know!

Thanks,
Fab

 

[anodos]

Ah, I see. Thanks for clearing that up.

I have one other question if I may. I'd like to have an AD account that is effectively storage admin - i.e., has full access to all the data being exported. Under windows, however, if you give a user full control over their own directory there's nothing stopping them from removing the ACL in place for the storage admin. Is there a way of doing what I want here?

In the example above, bacadm is my storage admin and I would like it to have full access to all shares.

My storage pool looks like this

store/
store/group/
store/group/group1
etc..
store/home/
store/home/user1
etc...

Effectively, I'd like the storage admin account to have access from store down in a way that is immutable and is inherited all the way down the tree. Is this possible?

If I'm not making sense please let me know!

Thanks,
Fab

See S-1-3-4 (OWNER-RIGHTS) and corresponding microsoft documentation. We support this over SMB, but I probably won't expose it in the GUI until 12.0.

https://support.microsoft.com/en-us...rity-identifiers-in-windows-operating-systems

 

[Fab Sidoli]

See S-1-3-4 (OWNER-RIGHTS) and corresponding microsoft documentation. We support this over SMB, but I probably won't expose it in the GUI until 12.0.

https://support.microsoft.com/en-us...rity-identifiers-in-windows-operating-systems

Not sure I understand, but hopefully my Windows admin will!

 

[anodos]

Not sure I understand, but hopefully my Windows admin will!

It's a rather obscure point in ACLs / windows administration. You can set an ACL that sets an upper bound on the permissions granted to a person by virtue of being the file's owner. This _only_ applies through the SMB protocol on FreeNAS.

 

[Fab Sidoli]

It's a rather obscure point in ACLs / windows administration. You can set an ACL that sets an upper bound on the permissions granted to a person by virtue of being the file's owner. This _only_ applies through the SMB protocol on FreeNAS.

It sound like this could be useful then, not least because I only plan to use the SMB protocol to export to linux and windows clients.