question on ACL for SMB share

[shewless]

Hi,
I have a directory that I want to give "everyone" access to via SMB. I want "everyone" to be able to read, write, create files but NOT delete, append, change permissions.
I also want users of the group "mygroup" to have the ability to basically do everything.

This seems to work but I wanted to double check it:

Code:

# file: .
# owner: root
# group: mygroup
         group@:rwxpDdaARWcCos:fd-----:allow
         everyone@:---pDd-A-W-Co-:fd-----:deny
         everyone@:rwx---a-R-c--s:fd-----:allow

I have some questions:

1. I didn't specify an "owner" because I allow guest access and if a guest creates a file it will be owned by them (nobody). I want them to have the same permissions as "everyone"... Is that safe or should I add an explicit owner ACL?
2. I _had_ to add the deny rule for append, delete, etc. Simply omitting it from the allow rule didn't work. Why is that?
3. If I ssh into my pool as root I can delete files in my dataset. Even though I would expect "root" to follow the ACLs and it should be treated as "everyone" because it's not the owner nor in the group of the file (and even if it was the owner I'd expect it to follow the "everyone" rule. Why is that? Does "rm" on local disk follow the "chmod" rules and not the ACLs?

Thank you

 

[anodos]

Hi,
I have a directory that I want to give "everyone" access to via SMB. I want "everyone" to be able to read, write, create files but NOT delete, append, change permissions.
I also want users of the group "mygroup" to have the ability to basically do everything.

This seems to work but I wanted to double check it:

Code:

# file: .
# owner: root
# group: mygroup
         group@:rwxpDdaARWcCos:fd-----:allow
         everyone@:---pDd-A-W-Co-:fd-----:deny
         everyone@:rwx---a-R-c--s:fd-----:allow

I have some questions:

1. I didn't specify an "owner" because I allow guest access and if a guest creates a file it will be owned by them (nobody). I want them to have the same permissions as "everyone"... Is that safe or should I add an explicit owner ACL?
2. I _had_ to add the deny rule for append, delete, etc. Simply omitting it from the allow rule didn't work. Why is that?
3. If I ssh into my pool as root I can delete files in my dataset. Even though I would expect "root" to follow the ACLs and it should be treated as "everyone" because it's not the owner nor in the group of the file (and even if it was the owner I'd expect it to follow the "everyone" rule. Why is that? Does "rm" on local disk follow the "chmod" rules and not the ACLs?

Testing permissions should be done via the protocol in question, not via SSH. You will get different results. If you want more faithful windows-style semantics for ACLs over SMB remove zfsacl and zfs_space and replace with ixnas.

 

[shewless]

Testing permissions should be done via the protocol in question, not via SSH. You will get different results. If you want more faithful windows-style semantics for ACLs over SMB remove zfsacl and zfs_space and replace with ixnas.

Hello.
I did do my testing over SMB and it works as I expect (I'm just trying to verify I followed the best practices and don't have any loopholes).
Since I am changing ZFS filesystem ACLs I would expect them to be enforced on the local filesystem as well though.. is that not the case?

I'm not sure if I want more failful windows-style semantics... :)

 

[anodos]

Hello.
I did do my testing over SMB and it works as I expect (I'm just trying to verify I followed the best practices and don't have any loopholes).
Since I am changing ZFS filesystem ACLs I would expect them to be enforced on the local filesystem as well though.. is that not the case?

I'm not sure if I want more failful windows-style semantics... :)

NFSv4 ACL behavior is enforced at the filesystem level. In this case write implies delete for allow ACEs. This is documented in RFC3530. NTFS behavior is enforced at the SMB level.

 

[shewless]

NFSv4 behavior is enforced at the filesystem level. In this case write implies delete for allow ACEs. This is documented in RFC3530. NTFS behavior is enforced at the SMB level.

Interesting. In your statement above it seems to be that "NFSFv4" behavior on filesystem is different than "NTFS" on SMB.

Is there anyway to make them the same? Perhaps that's not worth the effort...
Is there a way (in NFSv4) to allow file creation but disallow file deletes?

I have some "light" reading now with RFS3530 :)

 

[anodos]

Interesting. In your statement above it seems to be that "NFSFv4" behavior on filesystem is different than "NTFS" on SMB.

Is there anyway to make them the same? Perhaps that's not worth the effort...
Is there a way (in NFSv4) to allow file creation but disallow file deletes?

Yes, but you lose the ability to rename files.

 

[shewless]

Yes, but you lose the ability to rename files.

I'd be okay with that. Any hints on the ACL I would set to allow write, but not delete or rename?

 

[shewless]

I see this in the permission overview article:

• In FreeBSD presently "write data" (w) implies "delete" (D) and "delete child" (d). This issue is mitigated in the ixnas module starting in 11.3.

I don't see that problem via SMB though.

So if I share my dataset via samba and set the ACLs as in my initial post I find that I am able to prevent "delete" even without using the ixnas module. Perhaps that is because I am explicitly denying delete?

 

[shewless]

Okay I think I get it. It seems the root user has some super power to modify/delete files and ACLs regardless of what the ACLs are set to.
I can essentially set a "deny everything for everyone" ACL and root can still change directories, create files, etc.

Normal users seem to be subject to the ACLs (phew).

So my initial permission set:

Code:
# file: .
# owner: root
# group: mygroup
group@:rwxpDdaARWcCos:fd-----:allow
everyone@:---pDd-A-W-Co-:fd-----:deny
everyone@:rwx---a-R-c--s:fd-----:allow

Seems to work as I would expect. It allows users to create files, but NOT delete files. This works via SMB as well as local filesystem (as long as you're not root).

@anodos it seems if you put a "delete" deny rule above the "write" allow rule that you can work around the "write implies delete" problem that you are referring to.

Thanks

 

[anodos]

@anodos it seems if you put a "delete" deny rule above the "write" allow rule that you can work around the "write implies delete" problem that you are referring to.

Thanks

Yes, this is a known behavior. Explicit deny entries are honored in this case. Over the SMB protocol with ixnas enabled (the default in 11.3), omission of delete is sufficient.

 

[shewless]

Is there any risk in enabling ixnas in 11.2U6 or should I just wait for 11.3?

 

[TurtleFX]

Testing permissions should be done via the protocol in question, not via SSH. You will get different results. If you want more faithful windows-style semantics for ACLs over SMB remove zfsacl and zfs_space and replace with ixnas.

Hi,

FreeNAS 11.3 was released and I’m a bit confused with default VFS Objects.
On 11.3, by default, VFS Objects for new shares are: ixnas, streams_xattr
Previously default VFS Objects were: streams_xattr, zfs_space, zfsacl

However, it is still stated in the 11.3-RELEASE docummentation that zfs_space and zfsacl are enabled by default.
What are the correct settings? Are zfs_space and zfsacl replaced by ixnas and it should be enabled (zfs_space and zfsacl removed) for all older shares?

Also, I want to setup Syncthing jail and use it on dataset which is shared via SMB. Syncthing uses chmod.
Is there any way to make Syncthing work on SMB share? e.g. maybe newly added ixnas:zfsacl_sortaces=True and setting aclmode=passthrough on dataset would work?