FreeNAS ACLs and a somewhat sticky executable bit

[muppet_3000]

Hi Everyone,

I'm a new FreeNAS user but I'm pretty certain I'm in the right place for this post. Please redirect me if not.

I'm in the process of testing out my various use-cases for FreeNAS which is replacing a CentOS 7 server that just hosted a series of NFS shares that were mounted to various other machines on the network.
I have always used ACLs to restrict access and various permissions on my folders in the past (I'm not an expert on them but I know enough to give certain groups full access, certain other groups only read access and everyone else no access etc. etc.)
In the past I have always set the 'X' (note capitalisation) but on folders to signify that anything created under the directory (and all subdirs) should have the executable bit set if either the file is already executable OR if it is a directory.

However, with FreeNAS it would appear that the only way to achieve any form of executable bit is to have it set recursively for all created files and directories under the shared volume. I have logged onto the server using SSH to attempt to manually set the lower case "x" to an upper-case one using setfacl but I get setfacl: malformed ACL: "access permissions" field contains invalid flag "X` in response. Making me think that BSD/FreeNAS simply does not support this flag and as such there's no way to achieve this.

It's not the end of the world, I'd just rather not every single file I create on the volume have it's executable bit set (e.g. text files, jpeg files etc.).

Some helpful/important notes:

• This occurs both via the NFS share but also if the file is created locally on the freeNAS box indicating that it is the ACLs that are the issue not the share
• If I remove the ACLs altogether the sticky executable bit problem also goes away
• I have tried looking for a definitive answer to this elsewhere online but haven't been able to find one

Here are the permissions that are set on the folder in question:

Code:

root@freenas[/mnt/storage]# getfacl test_restricted                                                     
# file: test_restricted
# owner: root
# group: restricted_group
group:restricted_group:rwxpDdaARWc--s:-------:allow
            owner@:rwxpDdaARWcCos:fd-----:allow
            group@:rwxpDdaARWc--s:fd-----:allow
         everyone@:--------------:fd-----:allow

Hopefully I haven't missed anything, please ask if there's any more information required for debug.

What I'm after is either:

• No FreeNAS/BSD doesn't support this, get over it and move on with your life
  or
• Yes here's the relevant option to tick in the GUI that will solve all of your problems in life (can't believe you didn't find this in the first place)

Thanks in advance!

 

[anodos]

To have execute on directories, but not files, you can use the ACL manager to set an entry with flags set to ADVANCED: [DIRECTORY_INHERIT]. The ACL manager works by calculating an array of ACLs based on the one provided by the user and then applying them (choosing particular array member based on depth in the fts tree). This means it _always_ replaces the ACLs with the ones specified by the user (much like Windows with auto-inherited ACLs). At some point I plan to bring in support for ACL flags (auto-inherit, protected), but that is for the future.

This means that the ACL manager will _not_ preserve the execute bit on existing files that have it set. You can make a feature request for this, but it will require some non-trivial changes to our acl tool.

 

[anodos]

I suppose I could possibly have the ACL manager be somewhat more intelligent and have it strip / replace only "inherited" ACL entries. This will be somewhat more Windows-like. I will need to add support for the auto-inherit and protected flags in this case so that users can turn off propagated ACL changes for parts of their directory tree. So probably not anytime soon (not 11.3, possibly not 12.0). Our GUI tools for managing ACLs currently operate at only a dataset level.

 

[muppet_3000]

Thanks for the swift response.

I have tried changing the ACL flags to use "ADVANCED" with "Directory Inherit" checked (this is the only option that I have checked). This ends up with the correct options for directories but all normal files have no permissions at all (snippet below).

Code:

[cms@mickey free_nas_test]$ ll test_restricted/
total 11
----------. 1 root restricted_group 0 Aug  5 09:58 blah
----------. 1 cms  restricted_group 0 Aug  5 12:41 blah2
----------. 1 cms  restricted_group 0 Aug  5 12:43 blah3
----------. 1 cms  restricted_group 0 Aug  5 09:59 cms
----------. 1 cms  restricted_group 0 Aug  5 10:01 cms2
----------. 1 cms  restricted_group 0 Aug  5 10:15 cms3
----------. 1 cms  restricted_group 0 Aug  5 10:18 cms4
----------. 1 cms  restricted_group 0 Aug  5 10:27 cms5
----------. 1 cms  restricted_group 0 Aug  5 10:28 cms6
----------. 1 cms  restricted_group 5 Aug  5 12:33 cms7
----------. 1 cms  restricted_group 0 Aug  5 12:36 cms8
----------. 1 cms  restricted_group 0 Aug  5 12:49 mokey
----------. 1 root restricted_group 0 Aug  5 09:57 root
----------. 1 root restricted_group 7 Aug  5 12:35 root2
----------. 1 root restricted_group 0 Aug  5 10:02 root_local
drwxrwx---. 2 root restricted_group 2 Aug  5 10:22 root_local_2
----------. 1 root restricted_group 0 Aug  5 10:22 root_local_3
----------. 1 root restricted_group 0 Aug  5 10:28 root_local_4
----------. 1 root restricted_group 7 Aug  5 12:34 root_local_5
----------. 1 root restricted_group 0 Aug  5 10:15 sudo_test
drwxrwx---. 2 cms  restricted_group 2 Aug  5 10:18 tmp

Have I missed something? Do I need another option checked as well?

Without the ability to write to files etc. it's somewhat pointless. (I'm pretty certain I'm just missing 1 more permission but given there are several permutations of options I don't feel like trying them all until they work).

 

[anodos]

Thanks for the swift response.

I have tried changing the ACL flags to use "ADVANCED" with "Directory Inherit" checked (this is the only option that I have checked). This ends up with the correct options for directories but all normal files have no permissions at all (snippet below).

Code:

[cms@mickey free_nas_test]$ ll test_restricted/
total 11
----------. 1 root restricted_group 0 Aug  5 09:58 blah
----------. 1 cms  restricted_group 0 Aug  5 12:41 blah2
----------. 1 cms  restricted_group 0 Aug  5 12:43 blah3
----------. 1 cms  restricted_group 0 Aug  5 09:59 cms
----------. 1 cms  restricted_group 0 Aug  5 10:01 cms2
----------. 1 cms  restricted_group 0 Aug  5 10:15 cms3
----------. 1 cms  restricted_group 0 Aug  5 10:18 cms4
----------. 1 cms  restricted_group 0 Aug  5 10:27 cms5
----------. 1 cms  restricted_group 0 Aug  5 10:28 cms6
----------. 1 cms  restricted_group 5 Aug  5 12:33 cms7
----------. 1 cms  restricted_group 0 Aug  5 12:36 cms8
----------. 1 cms  restricted_group 0 Aug  5 12:49 mokey
----------. 1 root restricted_group 0 Aug  5 09:57 root
----------. 1 root restricted_group 7 Aug  5 12:35 root2
----------. 1 root restricted_group 0 Aug  5 10:02 root_local
drwxrwx---. 2 root restricted_group 2 Aug  5 10:22 root_local_2
----------. 1 root restricted_group 0 Aug  5 10:22 root_local_3
----------. 1 root restricted_group 0 Aug  5 10:28 root_local_4
----------. 1 root restricted_group 7 Aug  5 12:34 root_local_5
----------. 1 root restricted_group 0 Aug  5 10:15 sudo_test
drwxrwx---. 2 cms  restricted_group 2 Aug  5 10:18 tmp

Have I missed something? Do I need another option checked as well?

Without the ability to write to files etc. it's somewhat pointless. (I'm pretty certain I'm just missing 1 more permission but given there are several permutations of options I don't feel like trying them all until they work).

You need a slightly more complex set of ACLs in this case. For example:

Code:

group:restricted_group:x:d-----:allow
group:restricted_group:rwpDdaARWc--s:df-----:allow

 

[muppet_3000]

Hi, thanks again for your help on this, that has indeed cracked it (I had to add the same setup for my owner@ and group@ as well).

For anyone else stumbling across this in the future here's what my acl's for the directory now look like:

Code:

root@freenas[/mnt/storage]# getfacl test_restricted
# file: test_restricted
# owner: root
# group: restricted_group
            owner@:--x-----------:-d-----:allow
            owner@:rw-pDdaARWcCos:fd-----:allow
            group@:--x-----------:-d-----:allow
            group@:rw-pDdaARWc--s:fd-----:allow
group:restricted_group:--x-----------:-d-----:allow
group:restricted_group:rw-pDdaARWc--s:fd-----:allow
         everyone@:--------------:fd-----:allow

Thankfully the GUI reverse engineered this for me so I now know how to replicate it in the GUI for other datapools. Essentially each of the above lines needs it's own ACL entry in the datapool ACL page which roughly translates as follows:

These are the two entries that translate to the "owner@" lines in my above code snip. The "permissions" that are selected on the second entry are: absolutely everything, apart from "execute"

You then rinse and repeat this for "group@" and "group - <targeted group name>".

========================================================

@anodos I find it strange that nobody has run into this scenario before. I would have assumed a common use-case was to use ACLs (I started with the pre-populated "restricted" set and then added my extra group) and to NOT have the executable bit set on all files that are created?

Perhaps this is just me coming from a security focused Linux background where 'executable' translates roughly in my head to "vulnerability" :P
Or, is this more based on the fact that the ACLs are somewhat "Windows/SAMBA" focussed and my lack of Windows sysadmin expertise puts me at a disadvantage?

Just curious as it feels like what I'm trying to do should be the "default" scenario when using ACLs i.e. Files - no executable bit, Folders - executable bit. One way that this could be "implemented" if you wanted to "fix" it for the future, would be to simply have the "RESTRICTED" option under "Default ACL options" auto-generate 4 ACL entries (like the screen grab above) instead of just 2 using the "basic" options. The downside is the fact it created a lot of "advanced" options which may put off the more casual user.

Either way, I'm really grateful for your help, this has unlocked my last blocker to a full scale migration! Cue 8TB of rsync-ing!!

 

[jsnas]

To have execute on directories, but not files, you can use the ACL manager to set an entry with flags set to ADVANCED: [DIRECTORY_INHERIT]. The ACL manager works by calculating an array of ACLs based on the one provided by the user and then applying them (choosing particular array member based on depth in the fts tree). This means it _always_ replaces the ACLs with the ones specified by the user (much like Windows with auto-inherited ACLs). At some point I plan to bring in support for ACL flags (auto-inherit, protected), but that is for the future.

This means that the ACL manager will _not_ preserve the execute bit on existing files that have it set. You can make a feature request for this, but it will require some non-trivial changes to our acl tool.

I confirmed the settings that @muppet_3000 explained in the above post (ie. using DIRECTORY_INHERIT) work for me as well, but it prevents any file from having "x" even if it originated with "x" on the source machine (in my case, from a Mac). I believe that's what you mean about _not_ preserving the execute bit on existing files that have it set, correct?

The use case I'd like to see this implemented for is backing up applications, which by definition need executable. Right now, I have to choose between having ALL files executable (incl. text, jpeg, etc.), or have NO files executable (incl. applications).

Is there any way I can avoid text/jpeg from being tagged "x", but still back up applications with "x"? For example, is there some way I could set DIRECTORY_INHERIT on a dataset, but use rsync (or some other non-drag-and-drop method?) to retain "x" for application files?

If not, should I file an enhancement request? I agree with @muppet_3000 that it seems like this should be the default behavior, as I can't think of a reason why someone wouldn't want this behavior.

Meanwhile, the only solution I can think is to backup applications as a MacOS (or Windows) disk image.

 

[jsnas]

Just politely bumping this. @anodos Do you have any thoughts on this topic (questions above)?