VirtualBox on non-global zones

Of course it's best to run VirtualBox from a non-global zone.
I have successfully tested this on VirtualBox version 4.2.18.
But, unfortunately, since 4.3 series, at least up to 4.3.4, it's broken.
Create and configure non-global zones adding the following:

# zonecfg -z vboxzone              
     "add device;                  
      set match=/dev/vboxdrv;      
      end"

# zonecfg -z vboxzone              
     "add device;                  
      set match=/dev/vboxusbmon;   
      end"

Next boot the non-global zone and install the VirtualBox package stream (.pkg) and its extension pack (.vbox-extpack) as performed in VirtualBox on the global zone.

Alternatively, for greater simplicity, instead of repeating the installation in the non-global zone, it may be well enough just to lofs map /opt/VirtualBox from the global zone and adjust PATH to include it.

# zonecfg -z vboxzone              
     "add fs;                  
      set type=lofs;   
      set dir=/opt/VirtualBox;   
      set special=/opt/VirtualBox;   
      end;   
      end"

NOTE
 

• Naturally, /dev/vboxusbmon is not applicable to Solaris 10.
• If on Solaris 11, consider making the zone immutable. 

   

VirtualBox on the global zone

It's relatively simple to have Solaris as a VirtualBox host.
Below is what I've found to be the cleaner steps for installation.
   
If upgrading, remove previous versions.
Each existing VM configuration won't be lost.
 
# pkgrm SUNWvbox
   
Download and extract it to an empty folder:
  
# tar xzf VirtualBox-<version>.tar.gz
 
The subsequent installation action (pkgadd) may create the directory /opt/VirtualBox. If you pre-created it as the mountpoint of a ZFS dataset dedicated to VirtualBox files, then make sure you adjust the ownership attributes (chgrp) to root:bin, otherwise the installation will fail.

NFSv4 ACL example 7

Granting webservd modify access on the contents of new subdirectories created by bob.
This could be viewed as a variation of example 1 but the action of creation depends on bob.
No other action will be necessary to prevent webservd from deleting the new subdirectories.

bob@box-01:~/dir1 $ mkdir subdir2
bob@box-01:~/dir1 $ ll -dV subdir2 
drwxr-xr-x   2 bob      staff      2 Jun 21 13:29 subdir2
                 owner@:rwxp-DaARWcCos:-------:allow
                 group@:r-x---a-R-c--s:-------:allow
              everyone@:r-x---a-R-c--s:-------:allow

bob@box-01:~/dir1 $ chmod A+user:webservd:w:di:allow subdir2
bob@box-01:~/dir1 $ ll -dV subdir2 
drwxr-xr-x+  2 bob      staff      2 Jun 21 13:29 subdir2
          user:webservd:-w------------:-di----:allow
                 owner@:rwxp-DaARWcCos:-------:allow
                 group@:r-x---a-R-c--s:-------:allow
              everyone@:r-x---a-R-c--s:-------:allow

webservd@box-01:/home/bob/dir1 $ ll
total 3
drwxr-xr-x+  2 bob      staff      2 Jun 21 13:29 subdir2

webservd@box-01:/home/bob/dir1 $ echo Hello > subdir2/file21
bash: subdir2/file21: Permission denied

webservd@box-01:/home/bob/dir1 $ mkdir subdir3
mkdir: Failed to make directory "subdir3"; Permission denied

bob@box-01:~/dir1 $ mkdir subdir2/folder1
bob@box-01:~/dir1 $ ll -dV subdir2/folder1/
drwxr-xr-x+  2 bob      staff      2 Jun 21 13:37 subdir2/folder1/
          user:webservd:-w------------:-d----I:allow
                 owner@:rwxp-DaARWcCos:-------:allow
                 group@:r-x---a-R-c--s:-------:allow
              everyone@:r-x---a-R-c--s:-------:allow

webservd@box-01:/home/bob/dir1 $ echo Hi > subdir2/folder1/file211 
webservd@box-01:/home/bob/dir1 $ echo Yup > subdir2/folder1/file212
webservd@box-01:/home/bob/dir1 $ ll subdir2/folder1/
total 3
-rw-r--r--   1 webservd webservd   3 Jun 21 13:40 file211
-rw-r--r--   1 webservd webservd   4 Jun 21 13:40 file212

webservd@box-01:/home/bob/dir1 $ rm -r subdir2/folder1
rm: Unable to remove directory subdir2/folder1: Permission denied

webservd@box-01:/home/bob/dir1 $ ll subdir2/folder1/
total 0

webservd@box-01:/home/bob/dir1 $ rm -fr subdir2
rm: Unable to remove directory subdir2/folder1: Permission denied
rm: Unable to remove directory subdir2: Permission denied
  

NFSv4 ACL example 6

Avoiding everyone reading non-trivial ACLs.

bob@box-01:~/dir1 $ mkdir subdir2
bob@box-01:~/dir1 $ touch subdir2/file1
bob@box-01:~/dir1 $ touch subdir2/file2
bob@box-01:~/dir1 $ ll -dV subdir2 
drwxr-xr-x   2 bob      staff       2 Jun 20 11:03 subdir2
                 owner@:rwxp-DaARWcCos:-------:allow
                 group@:r-x---a-R-c--s:-------:allow
              everyone@:r-x---a-R-c--s:-------:allow

webservd@box-01:/home/bob/dir1 $ ll -dV subdir2
drwxr-xr-x   2 bob      staff       2 Jun 20 11:03 subdir2
                 owner@:rwxp-DaARWcCos:-------:allow
                 group@:r-x---a-R-c--s:-------:allow
              everyone@:r-x---a-R-c--s:-------:allow

bob@box-01:~/dir1 $ chmod A2=everyone@:rxaRs:allow subdir2
bob@box-01:~/dir1 $ ll -dV subdir2
drwxr-xr-x   2 bob      staff       2 Jun 20 11:03 subdir2
                 owner@:rwxp-DaARWcCos:-------:allow
                 group@:r-x---a-R-c--s:-------:allow
              everyone@:r-x---a-R----s:-------:allow

webservd@box-01:/home/bob/dir1 $ ll subdir2
ls: can't read ACL on subdir2: Permission denied
total 2
-rw-r--r--   1 bob      staff       0 Jun 20 12:34 file1
-rw-r--r--   1 bob      staff       0 Jun 20 12:34 file2

But it's not yet OK because I expected it to "propagate" throughout subdirectories.
This didn't happen:

webservd@box-01:/home/bob/dir1 $ ll -dV subdir2/file1
-rw-r--r--   1 bob      staff       0 Jun 20 12:34 subdir2/file1
                 owner@:rw-p--aARWcCos:-------:allow
                 group@:r-----a-R-c--s:-------:allow
              everyone@:r-----a-R-c--s:-------:allow

Trying to address the above problem I've reached another hurdle: ACL inheritance.
That's not so straightforward: the ZFS aclinherit file-system property comes into play.
The default of aclinherit setting which is restricted, isn't suitable for the case.
owner@, group@ and/or everyone@ are discarded and recomputed from umask.
Thus, the solution seems to be passthrough or passthrough-x.
I'm still not sure if one of them would be preferable over the other.  

bob@box-01:~/dir1 $ zfs get aclinherit rpool/export/home/bob
NAME                   PROPERTY    VALUE          SOURCE
rpool/export/home/bob  aclinherit  passthrough    local

bob@box-01:~/dir1 $ mkdir subdir4
bob@box-01:~/dir1 $ ll -dV subdir4
drwxr-xr-x   2 bob      staff       2 Jun 20 14:36 subdir4
                 owner@:rwxp-DaARWcCos:-------:allow
                 group@:r-x---a-R-c--s:-------:allow
              everyone@:r-x---a-R-c--s:-------:allow

bob@box-01:~/dir1 $ chmod A+user:webservd:rxaR:fd:allow subdir4
bob@box-01:~/dir1 $ chmod A1=owner@:rwxpDaARWcCos:fd:allow subdir4
bob@box-01:~/dir1 $ chmod A2=group@:rxaRcs:fd:allow subdir4
bob@box-01:~/dir1 $ chmod A3=everyone@:c:fd:deny subdir4
bob@box-01:~/dir1 $ ll -dV subdir4
drwxr-x---+  2 bob      staff       3 Jun 20 15:08 subdir4
          user:webservd:r-x---a-R-----:fd-----:allow
                 owner@:rwxp-DaARWcCos:fd-----:allow
                 group@:r-x---a-R-c--s:fd-----:allow
              everyone@:----------c--s:fd-----:deny

bob@box-01:~/dir1 $ touch subdir4/file42
bob@box-01:~/dir1 $ ll -dV subdir4/file42
-rwxr-x---+  1 bob      staff       0 Jun 20 15:44 subdir4/file42
          user:webservd:r-x---a-R-----:------I:allow
                 owner@:rwxp-DaARWcCos:------I:allow
                 group@:r-x---a-R-c--s:------I:allow
              everyone@:----------c--s:------I:deny

webservd@box-01:/home/bob/dir1 $ ll -dV subdir4
ls: can't read ACL on subdir4: Permission denied
drwxr-x---   2 bob      staff       4 Jun 20 15:44 subdir4

webservd@box-01:/home/bob/dir1 $ ll -dV subdir4/file42
ls: can't read ACL on subdir4/file42: Permission denied
-rwxr-x---   1 bob      staff       0 Jun 20 15:44 subdir4/file42

  

NFSv4 ACL example 5

Creating a drop-box for user webservd on a subdirectory owned by user bob.

bob@box-01:~/dir1 $ mkdir subdir1
bob@box-01:~/dir1 $ chmod 750 subdir1
bob@box-01:~/dir1 $ ll -dV subdir1
drwxr-x---   2 bob      staff          2 Jun 20 10:25 subdir1
                 owner@:rwxp-DaARWcCos:-------:allow
                 group@:r-x---a-R-c--s:-------:allow
              everyone@:------a-R-c--s:-------:allow 
webservd@box-01:/home/bob/dir1 $ ll subdir1
subdir1: Permission denied
total 3
webservd@box-01:/home/bob/dir1 $ rmdir subdir1
rmdir: directory "subdir1": Search or write permission needed
webservd@box-01:/home/bob/dir1 $ rm -r subdir1
rm: cannot read directory subdir1: Permission denied
webservd@box-01:/home/bob/dir1 $ cd subdir1
bash: cd: subdir1: Permission denied

bob@box-01:~/dir1 $ chmod A+user:webservd:wxaRcs:allow subdir1
bob@box-01:~/dir1 $ ll -dV subdir1
drwxr-x---+  2 bob      staff          2 Jun 20 10:34 subdir1
          user:webservd:-wx---a-R-c--s:-------:allow
                 owner@:rwxp-DaARWcCos:-------:allow
                 group@:r-x---a-R-c--s:-------:allow
              everyone@:------a-R-c--s:-------:allow 
webservd@box-01:/home/bob/dir1 $ ll subdir1
subdir1: Permission denied
total 3
webservd@box-01:/home/bob/dir1 $ rmdir subdir1
rmdir: directory "subdir1": Search or write permission needed
webservd@box-01:/home/bob/dir1 $ rm -r subdir1
rm: cannot read directory subdir1: Permission denied
webservd@box-01:/home/bob/dir1 $ cd subdir1
webservd@box-01:/home/bob/dir1/subdir1 $
webservd@box-01:/home/bob/dir1/subdir1 $ ll -a
.: Permission denied
total 3

webservd@box-01:/home/bob/dir1/subdir1 $ echo 'Hello!' > file1
webservd@box-01:/home/bob/dir1/subdir1 $ ll -a
.: Permission denied
total 3
webservd@box-01:/home/bob/dir1/subdir1 $ rm *
rm: *: No such file or directory

bob@box-01:~/dir1 $ cat subdir1/file1
Hello!

NFSv4 ACL example 4

Granting webservd permission to just write to (not read from) a single file (mode 640) on a directory owned by bob. Note that according to the initial setup, by "other" permission bit, webservd wouldn't be able to write to any file at all.

bob@box-01:~/dir1 $ printf "Hello" > file2
bob@box-01:~/dir1 $ chmod 640 file2
bob@box-01:~/dir1 $ ll -dV file2
-rw-r-----   1 bob      staff          5 Jun 20 10:12 file2
                 owner@:rw-p--aARWcCos:-------:allow
                 group@:r-----a-R-c--s:-------:allow
              everyone@:------a-R-c--s:-------:allow

bob@box-01:~/dir1 $ chmod A+user:webservd:waRcs:allow file2
bob@box-01:~/dir1 $ ll -dV file2
-rw-r-----+  1 bob      staff          5 Jun 20 10:12 file2
          user:webservd:-w----a-R-c--s:-------:allow
                 owner@:rw-p--aARWcCos:-------:allow
                 group@:r-----a-R-c--s:-------:allow
              everyone@:------a-R-c--s:-------:allow

webservd@box-01:/home/bob/dir1 $ cat file2
cat: cannot open file2: Permission denied

webservd@box-01:/home/bob/dir1 $ echo ', world!' >> file2
webservd@box-01:/home/bob/dir1 $ ll file2
-rw-r-----+  1 bob      staff         14 Jun 20 10:15 file2

bob@box-01:~/dir1 $ cat file2
Hello, world!

webservd@box-01:/home/bob/dir1 $ rm file2
rm: file2 not removed: Permission denied
  

NFSv4 ACL example 3

Granting webservd permission to read from a single file (mode 640) on a directory owned by bob. Note that according to the initial setup, by "other" permission bit, webservd would be able to read any file.  

bob@box-01:~/dir1 $ echo Hello > file2
bob@box-01:~/dir1 $ chmod 640 file2
bob@box-01:~/dir1 $ ll
total 1
-rw-r-----   1 bob      staff          6 Jun 20 09:35 file2

webservd@box-01:/home/bob/dir1 $ cat file2
cat: cannot open file2: Permission denied

bob@box-01:~/dir1 $ chmod A+user:webservd:raRcs:allow file2
bob@box-01:~/dir1 $ ll -dV file2
-rw-r-----+  1 bob      staff          6 Jun 20 09:35 file2
          user:webservd:r-----a-R-c--s:-------:allow
                 owner@:rw-p--aARWcCos:-------:allow
                 group@:r-----a-R-c--s:-------:allow
              everyone@:------a-R-c--s:-------:allow

webservd@box-01:/home/bob/dir1 $ cat file2
Hello

webservd@box-01:/home/bob/dir1 $ rm file2
rm: file2: override protection 640 (yes/no)? y
rm: file2 not removed: Permission denied
  

NFSv4 ACL example 2

Grating user webservd permission to create files on a directory owned by bob. Note that according to the initial setup, webservd won't be able to do that unless additional permission is granted.

 But be aware!  
This will also allow webservd to delete all files on dir1! (and even dir1 itself!)

webservd@box-01:/home/bob/dir1 $ touch file1
touch: cannot create file1: Permission denied

bob@box-01:~ $ chmod A0=user:webservd:rwxaRcs:allow dir1
bob@box-01:~ $ ll -dV dir1
drwxr-xr-x+  2 bob      staff          2 Jun 20 09:01 dir1
          user:webservd:rwx---a-R-c--s:-------:allow
                 owner@:rwxp-DaARWcCos:-------:allow
                 group@:r-x---a-R-c--s:-------:allow
              everyone@:r-x---a-R-c--s:-------:allow

webservd@box-01:/home/bob/dir1 $ touch file1
webservd@box-01:/home/bob/dir1 $ ll
total 1
-rw-r--r--   1 webservd webservd       0 Jun 20 09:13 file1

webservd@box-01:/home/bob/dir1 $ rm file2
rm: file2: override protection 640 (yes/no)? y

webservd@box-01:/home/bob/dir1 $ ll
total 0
  

NFSv4 ACL example 1

Granting user webservd the permission to create a subdirectory of a directory owned by bob. Note that webservd won't be able to remove this subdirectory unless he's also granted D permission on the parent directory or gives himself d permission on his subdirectory. 

webservd@box-01:/home/bob/dir1 $ mkdir subdir1
mkdir: Failed to make directory "subdir1"; Permission denied 

bob@box-01:~ $ chmod A+user:webservd:rxpaRcs:allow dir1
bob@box-01:~ $ ll -dV dir1
drwxr-xr-x+  2 bob      staff          2 Jun 20 08:11 dir1
          user:webservd:r-xp--a-R-c--s:-------:allow
                 owner@:rwxp-DaARWcCos:-------:allow
                 group@:r-x---a-R-c--s:-------:allow
              everyone@:r-x---a-R-c--s:-------:allow 
webservd@box-01:/home/bob/dir1 $ mkdir subdir1
webservd@box-01:/home/bob/dir1 $ ll -dV subdir1
drwxr-xr-x   2 webservd webservd       2 Jun 20 08:23 subdir1
                 owner@:rwxp-DaARWcCos:-------:allow
                 group@:r-x---a-R-c--s:-------:allow
              everyone@:r-x---a-R-c--s:-------:allow

webservd@box-01:/home/bob/dir1 $ rmdir subdir1
rmdir: directory "subdir1": Search or write permission needed

webservd@box-01:/home/bob/dir1 $ rm -r subdir1
rm: Unable to remove directory subdir1/: Permission denied

bob@box-01:~ $ chmod A0=user:webservd:rxpDaRcs:allow dir1
bob@box-01:~ $ ll -dV dir1
drwxr-xr-x+  3 bob      staff          3 Jun 20 08:23 dir1
          user:webservd:r-xp-Da-R-c--s:-------:allow
                 owner@:rwxp-DaARWcCos:-------:allow
                 group@:r-x---a-R-c--s:-------:allow
              everyone@:r-x---a-R-c--s:-------:allow

webservd@box-01:/home/bob/dir1 $ rmdir subdir1
webservd@box-01:/home/bob/dir1 $ ll
total 0

bob@box-01:~ $ chmod A0=user:webservd:rxpdaRcs:allow dir1
bob@box-01:~ $ ll -dV dir1
drwxr-xr-x+  3 bob      staff          3 Jun 20 08:35 dir1
          user:webservd:r-xpd-a-R-c--s:-------:allow
                 owner@:rwxp-DaARWcCos:-------:allow
                 group@:r-x---a-R-c--s:-------:allow
              everyone@:r-x---a-R-c--s:-------:allow

webservd@box-01:/home/bob/dir1 $ mkdir subdir2
webservd@box-01:/home/bob/dir1 $ rmdir subdir2
rmdir: directory "subdir2": Search or write permission needed

bob@box-01:~ $ chmod A0=user:webservd:rxpaRcs:allow dir1
bob@box-01:~ $ ll -dV dir1
drwxr-xr-x+  3 bob      staff          3 Jun 20 08:35 dir1
          user:webservd:r-xp--a-R-c--s:-------:allow
                 owner@:rwxp-DaARWcCos:-------:allow
                 group@:r-x---a-R-c--s:-------:allow
              everyone@:r-x---a-R-c--s:-------:allow

bob@box-01:~ $ ll -dV dir1/subdir2
drwxr-xr-x   2 webservd webservd       2 Jun 20 08:35 dir1/subdir2
                 owner@:rwxp-DaARWcCos:-------:allow
                 group@:r-x---a-R-c--s:-------:allow
              everyone@:r-x---a-R-c--s:-------:allow

bob@box-01:~ $ chmod A0=owner@:rwxpdDaARWcCos:allow dir1/subdir2
chmod: ERROR: Failed to set ACL: Not owner

bob@box-01:~ $ chmod A+user:webservd:rxdaRcs:allow dir1/subdir2
chmod: ERROR: Failed to set ACL: Not owner

webservd@box-01:/home/bob/dir1 $ chmod A0=owner@:rwxpdDaARWcCos:allow subdir2
webservd@box-01:/home/bob/dir1 $ ll -dV subdir2
drwxr-xr-x+  2 webservd webservd       2 Jun 20 08:35 subdir2
                 owner@:rwxpdDaARWcCos:-------:allow
                 group@:r-x---a-R-c--s:-------:allow
              everyone@:r-x---a-R-c--s:-------:allow 

webservd@box-01:/home/bob/dir1 $ rmdir subdir1
webservd@box-01:/home/bob/dir1 $ ll
total 0
  

NFSv4 ACL examples setup

With respect to NFSv4 ACL permissions, 
I shall be using the following setup in a series of examples:

• An ordinary account, such as, bob.
• The webservd account; just to make things more interesting.
• A base directory within ~bob, such as dir1, to play with.
• The default umask 0022.

So the starting point is as follows:

$ su - bob
Oracle Corporation    SunOS 5.11    11.0    April 2012

bob@box-01:~ $ ll -a
...
drwxr-xr-x   2 bob      staff        2 Jun 20 08:11 dir1

bob@box-01:~ $ ll -dV dir1
drwxr-xr-x   2 bob      staff        2 Jun 20 08:11 dir1
                 owner@:rwxp-DaARWcCos:-------:allow
                 group@:r-x---a-R-c--s:-------:allow
              everyone@:r-x---a-R-c--s:-------:allow

bob@box-01:~ $ umask
0022 
  
The examples series are:

• NFSv4 ACL example 1
• NFSv4 ACL example 2 
• NFSv4 ACL example 3 
• NFSv4 ACL example 4 
• NFSv4 ACL example 5 
• NFSv4 ACL example 6 
• NFSv4 ACL example 7 

   

NFSv4 ACL permissions sets

With respect to NFSv4 ACL permissions,
Solaris offers the following predefined permissions sets:

                                   attr xattr acl own 
                                   ---- ----- --- --- 

         full_set = rwx   p   dD   aA   RW    cC  o   s

       modify_set = rwx   p   dD   aA   RW    c_  _   s

         read_set = r__   _   __   a_   R_    c_  _   s

        write_set = _w_   p   __   _A   _W    __  _   s  
Thus:
       modify_set = read_set | write_set | (x dD)
or yet:
       modify_set = full_set & ~(C o)
   
Note the following resemblance between the trivial-ACL (UNIX standard rwx flags) and the NFSv4 predefined permissions sets (owner implies C o):

      UNIX                NFSv4
      ----      -------------------------
      r    --->  read_set   =  r      ...

       w   ---> write_set   =   w  p  ...
        x  --->                  x  
      r-x  --->  read_set   |    x     
      rwx  --->  modify_set

Again, these are the predefined permissions sets according to Solaris.
It may be useful to contrast to Windows (SMB/CIFS) permission sets. 
  

NFSv4 ACL summary

Solaris extends UNIX file system permissions through more granular NFSv4-like ACLs. 
The standard UNIX file system permissions are now simply called trivial-ACLs.
For plenty of information on ACLs, refer to acl(5).
 
Each ACL has many ordered allowing and/or denying ACEs combining the following permission and inheritance flags associated to a certain account.

The following is a list of just the permission flags:
(theoretically the most difficult part of an ACL)

 flag   file                    directory (not its contents) 

  r     read_data               list_directory  (ls) 
  w     write_data              add_file        (+modify, +delete) 
  x     execute                 execute         (=search, =enter)     

  p     append_data             add_subdirectory
  D                             delete_child

  d     delete                  delete

  a     read_attributes  (ls -l) 
  A     write_attributes

  R     read_xattr 
  W     write_xattr

  c     read_acl
  C     write_acl

  o     write_owner

  s     synchronize (not supported)


At least in Solaris, the compact form of an ACE comprises 4 parts delimited by colons and which are displayed with the -V option of ls(1). As a minimal example, the following ACL has just a single ACE:

prime@box-01:/export/project# ll -V Europe/Memo-01.txt
-rwx------+  1 prime  staff ... Europe/Memo-01.txt
             user:prime:rwxpdDaARWcCos:-------:allow

Briefly, these 4 parts are:

1. The account (sometimes called principal or identity).
   It can be one of the following:
    
   • owner@          - for the Current Owner (prime)
   • group@          - for the Current Group (staff)
   • everyone@       - for the rest of the world
   • user:<account>  - for any other user account
   • group:<account> - for any other group account
    
2. The permission flags already described.
    
3. The inheritance flags:
   (it's advisable not to mix f and d on a single ACE)
   (only the last 2 seem more reasonable applicable to files)
    
      f-i----  - Only applies to new files
      f--n---  - Also inherit just one level down to new files
      -d-----  - Also inherit to new subdirectories
      -di----  - Only applies to new subdirectories
      -d-n---  - Also inherit just one level down to new subdirectories
      -------  - No inheritance; all permissions are local only
      ------I  - The permissions have been inherited
    
4. The type of the ACE.
   Solaris 11.3 supports just 2 types: allow or deny.
   The deny type supports reasoning in terms of complements.
   (for instance: No Access could be thought as deny Full Control)

NOTE

The n flag in the inheritance flags (part 3 above) is a kind of general idiom when some sort of inheritance or hierarchy is involved. It's sort of a practical way of referring to the immediate (first generation) children of a parent.

As seen above, more options were added to the ls (the v|V options) and chmod (the A option) commands in order to allow managing these extended permissions. In addition, zfs(1M) properties (such as aclmode / aclinherit) affects the overall behavior as well.
  
To help start understanding the big picture of these complex extended permissions, it can be useful take a look at how are they generally gathered together in permissions sets as well as a few examples.

As extension to the topic in may be interesting to find out about mapping NFSv4 permissions to Windows environments or more generally to any platform that talks the SMB/CIFS protocol where permissions have to be dealt with.