The graphical interface of the ACL editors (Directory Permissions and File Permissions) are powerful yet reasonably nice, simple, concise and straightforward. And I mostly like it.
Let's focus just on the permissions sets which are listed on the "second colon" of the listboxes labeled Name for each user or group to which the ACL is to be enforced.
The first thing to note is that Directories Permissions have two pairs of parenthesis while Files Permissions just have one. On the former, the first pair of parenthesis refers to the permissions that apply just to the directory (not the files in it), while the second pair of parenthesis refers to the permissions of the (current or new) files in the directory (depending on the setting of the checkbox which text is Replace Permissions on Existing Files).
The second thing to note is that most of the permissions sets that are list on the dropdown-listbox labeled Type of Access are the "standard" ones (according to Windows). Whatever deviates from these is considered a Special Access case and treated accordingly in the interface.
The third thing to note is that on this world, exactly 6 permission flags (independent among each other) are recognized and they are as follows (but there are a few caveats around their names and effective meanings as it shall become more clear on the permissions sets below):
Permission Flag
R Read
W Write
X Execute
D Delete
P Change Permissions
O Take Ownership
The fourth thing to note is that from the Windows GUI ACL editors there's no direct way of telling if an ACL is being inherited or not. The rule is that if you override any ACL for a file system object than then what's previously inherited is copied alongside what's been changed.
Still solely from the Windows perspective let's summarize the ("standard", except for the Special Access) permissions sets as they are recognized by the system:
For directories:
Permission Set
(None ) (None ) No Access
(R_X___) (None ) List
(R_X___) (R_X___) Read
(_WX___) (None ) Add
(RWX___) (R_X___) Add & Read
(RWXD__) (RWXD__) Change
(All ) (All ) Full Control
(Other ) (Other ) Special Access
For files:
Permission Set
(None ) No Access
(R_X___) Read
(RWXD__) Change
(All ) Full Control
(Other ) Special Access
Now from the UNIX NFSv4 ACLs perspective each of the above permission set (interestingly) translates into the following (for simplicity here I'm intentionally omitting the name of the associated user or group that should be prefixed to each ACL):
No Access
(None)(None) rwxpdDaARWcCos:f-i----:deny
rwxpdDaARWcCos:-d-----:deny
List
(RX)(Not Specified) r-x---a-R-c--s:-d-----:allow
Read
(RX)(RX) r-x---a-R-c--s:f-i----:allow
r-x---a-R-c--s:-d-----:allow
Add
(WX)(Not Specified) -wxp--aA-Wc--s:-d-----:allow
Add & Read
(RWX)(RX) r-x---a-R-c--s:f-i----:allow
rwxp--aARWc--s:-d-----:allow
Change
(RWXD)(RWXD) rwxpd-aARWc--s:f-i----:allow
rwxpd-aARWc--s:-d-----:allow
Full Control
(All)(All) rwxpdDaARWcCos:f-i----:allow
rwxpdDaARWcCos:-d-----:allow
NOTE
The preceding series of ACLs is formatted in terms of directory permissions but the same translation applies to file permissions if you consider just the second pair of parenthesis and the respective ACL inheritance flags (between both colons in my listing) which contain an f but removing both the f and i. For instance, the Full Control for a file is depicted by the ACL rwxpdDaARWcCos:-------:allow
So, as one can see, for directories, except when (Not Specified) is involved, each pair of parenthesis actually translates into 2 NFSv4 ACLs, one for the directory (which contains the d flag) and another (which contains the f flag) for files (for being implictly inherited by new files or overriden in existing files within the directory, this last case depending on the checkbox which text is Replace Permissions on Existing Files).
For attempting the ultimate fine-grained ACL mapping between NT4 and UNIX I'll put the following (hopefully) final listing of this (long) post:
(Special Access)(R) r-----a-R-c--s:-------:allow
(Special Access)(W) -w-p---A-Wc--s:-------:allow
(Special Access)(X) --x---a---c--s:-------:allow
(Special Access)(D) ----d--------s:-------:allow
(Special Access)(P) -----------C-s:-------:allow
(Special Access)(O) ------------os:-------:allow
Well, beyond all the above, who knows, maybe someone can devise some useful and unanticipated sort of special access, but in general what's been seen is pretty much all about that.
With the knowledge of this post, it's not necessary to resort to a Windows box in order to set meaningful permissions according to Windows by using its GUI editors. You can do it from a Solaris 11.3 shell by using chmod(1).
