John M. Długosz
Contributor
- Joined
- Sep 22, 2013
- Messages
- 160
I've read the manual, and browsed through this Sharing forum and the Noobs forum. But I actually gathered some important information from reading bug tickets (and enhancement/change requests) relating to “ACL”! Specifically, the relationship between the classic Unix permissions and ACLs, and the intended workflow of setting up permissions through the Windows client.
Note that the Windows “Type of ACL” is completely broken: if selected, then no changes are made at all when the [Change] button is pressed to dismiss the dialog box. I suspect this is only a problem with the UI, and it might be possible to set it via the command prompt?
It is stated in the FreeNAS manual that Windows ACL is a superset of Unix ACL. Doing some digging via Google, I suspect that by “Unix ACL” it means NSFv4 ACLs (Summarized in Wikipedia, “FreeBSD supports POSIX.1e ACLs on UFS; and NFSv4 or Windows ACLs on UFS and ZFS. {ref}”
So, what is available in Windows ACLs that are absent in Unix ACLs?
In the bug tracker, I see things along the lines of disabling the Mode when Windows ACL is chosen (that's the case now), automatically setting reasonable mode on the dataset when Windows is selected, and various other tweeks “when Windows ACL is selected”.
What is the current state of affairs? I've noticed the GUI affect, but less visibly does using Windows ACL do anything other than make some additional access list features available? Does it interact with classic Mode differently, or at all? (after all, there is talk of setting sane default, so it must be not-ignored, right?) So, by using Unix ACLs, am I getting different behavior beyond some permission settings I've apparently not needed?
As mentioned earlier, for datasets intended for Windows clients, I've gleamed that the intent is to just set the Owner and Group when creating the dataset, and then do all the real permission settings via ACLs on a Windows machine.
Looking at the DACL ("security settings") via Windows file explorer, the initial settings are weird. I suppose it's "right" in having the desired effects, but the particular combination of tick-marks is not recognized as one of the standard recipes so it just shows as <special>; and it does not inherit permissions from the directory (and parent dir) but sets them on every file individually. When a file is copied to a subdirectory of the dataset being exposed via CIFS, where do the initial ACL come from? I changed the ACLs of the existing items including the directories,but I wonder if that will affect new items, and how so? I've not experimented to that point yet.
What I have done is set normal permission settings at the top level and had it recursively apply all the way down to existing items. Those settings are, in this case:
I created a new file, using various methods, and see that it is getting the expected (inherited) settings. Great! I copied a file to the dataset, and it also had those same settings, completely losing the original security settings. Copying from the NAS dataset to a local drive also changed the Permissions to that of a newly created file in the destination directory. So did "Move" — it kept the old Modified time, but reset the Permissions (all "inherited from parent" so implicit). In comparison, changing the Permissions to something novel, and then Moving the file within the same file system kept the Permissions. Copying to the NAS, on the other hand, lost them.
So an overarching question is, am I doing this correctly (in harmony with how the system works) or fighting it? Will there be any other problems when I start using this in earnest? Basically, after setting up the Dataset to at least allow me to write to it, do everything the same way as local files on Windows. (caveats as usual for not being in a Domain)
What happens to the classic Mode settings? Some of what I've read indicates that using them (via a command line on the NAS, I suppose) will cause bad and strange things to happen. But, when I look at "Security" on Windows, it appears that ACLs are indeed present already. I don't think a Unix user expects modes to be messed up and ACL installed instead in the event that a directory had been browsed by a windows client at some point in its history.
—John
Note that the Windows “Type of ACL” is completely broken: if selected, then no changes are made at all when the [Change] button is pressed to dismiss the dialog box. I suspect this is only a problem with the UI, and it might be possible to set it via the command prompt?
It is stated in the FreeNAS manual that Windows ACL is a superset of Unix ACL. Doing some digging via Google, I suspect that by “Unix ACL” it means NSFv4 ACLs (Summarized in Wikipedia, “FreeBSD supports POSIX.1e ACLs on UFS; and NFSv4 or Windows ACLs on UFS and ZFS. {ref}”
So, what is available in Windows ACLs that are absent in Unix ACLs?
In the bug tracker, I see things along the lines of disabling the Mode when Windows ACL is chosen (that's the case now), automatically setting reasonable mode on the dataset when Windows is selected, and various other tweeks “when Windows ACL is selected”.
What is the current state of affairs? I've noticed the GUI affect, but less visibly does using Windows ACL do anything other than make some additional access list features available? Does it interact with classic Mode differently, or at all? (after all, there is talk of setting sane default, so it must be not-ignored, right?) So, by using Unix ACLs, am I getting different behavior beyond some permission settings I've apparently not needed?
As mentioned earlier, for datasets intended for Windows clients, I've gleamed that the intent is to just set the Owner and Group when creating the dataset, and then do all the real permission settings via ACLs on a Windows machine.
Looking at the DACL ("security settings") via Windows file explorer, the initial settings are weird. I suppose it's "right" in having the desired effects, but the particular combination of tick-marks is not recognized as one of the standard recipes so it just shows as <special>; and it does not inherit permissions from the directory (and parent dir) but sets them on every file individually. When a file is copied to a subdirectory of the dataset being exposed via CIFS, where do the initial ACL come from? I changed the ACLs of the existing items including the directories,
What I have done is set normal permission settings at the top level and had it recursively apply all the way down to existing items. Those settings are, in this case:
- Everyone: Read
- Group "share": Read&execute, Read
- one specific user: Full control
I created a new file, using various methods, and see that it is getting the expected (inherited) settings. Great! I copied a file to the dataset, and it also had those same settings, completely losing the original security settings. Copying from the NAS dataset to a local drive also changed the Permissions to that of a newly created file in the destination directory. So did "Move" — it kept the old Modified time, but reset the Permissions (all "inherited from parent" so implicit). In comparison, changing the Permissions to something novel, and then Moving the file within the same file system kept the Permissions. Copying to the NAS, on the other hand, lost them.
So an overarching question is, am I doing this correctly (in harmony with how the system works) or fighting it? Will there be any other problems when I start using this in earnest? Basically, after setting up the Dataset to at least allow me to write to it, do everything the same way as local files on Windows. (caveats as usual for not being in a Domain)
What happens to the classic Mode settings? Some of what I've read indicates that using them (via a command line on the NAS, I suppose) will cause bad and strange things to happen. But, when I look at "Security" on Windows, it appears that ACLs are indeed present already. I don't think a Unix user expects modes to be messed up and ACL installed instead in the event that a directory had been browsed by a windows client at some point in its history.
—John
