Using FreeNAS 9.3 and trying to get my head around ACLs (sometimes it feels like they wrap themselves around my head) ...
In the process of converting Unix permissions to ACLs I had to clear the existing ACLs (they were a shambles of past attempts) and I used the command line in FreeNAS gui.
I used the BSD <setfacl> command with the -b switch that strips out all except the basic lines from the access lists.
Used it globally on shares using the <find> command to feed a list to <setfacl> as described elsewhere on the forums.
The basic lists then contained the defaults including a group@ entry of "everyone" with minimal permissions.
However I have found that Windows seems to process these lines in the ACLs according to the list sequence,
with first lines taking precedence.
The result is that a group@:everyone with no permissions can sometimes block the effect another lower line with user:name and active permissions.
When this happens, the user:name is not given their rightful permissions.
Removing the "group@:everyone" entries solved the problem, and in our case we do not want any guest access or everyone access.
I am posting this in case someone who understands these things can explain whether the group@:everyone is really necessary or should even be a default entry for security-conscious installations (as opposed to home user installs).
And maybe CyberJock could add a note to the book I thing he is writing.
In the process of converting Unix permissions to ACLs I had to clear the existing ACLs (they were a shambles of past attempts) and I used the command line in FreeNAS gui.
I used the BSD <setfacl> command with the -b switch that strips out all except the basic lines from the access lists.
Used it globally on shares using the <find> command to feed a list to <setfacl> as described elsewhere on the forums.
The basic lists then contained the defaults including a group@ entry of "everyone" with minimal permissions.
However I have found that Windows seems to process these lines in the ACLs according to the list sequence,
with first lines taking precedence.
The result is that a group@:everyone with no permissions can sometimes block the effect another lower line with user:name and active permissions.
When this happens, the user:name is not given their rightful permissions.
Removing the "group@:everyone" entries solved the problem, and in our case we do not want any guest access or everyone access.
I am posting this in case someone who understands these things can explain whether the group@:everyone is really necessary or should even be a default entry for security-conscious installations (as opposed to home user installs).
And maybe CyberJock could add a note to the book I thing he is writing.
