19 October 2010

Fun with FACLs

Quick, think of a way to give a specific user (jdoe) access to a
particular set of files which are owned by a different user (ivan)
and group (moskau).  Depending of what you are trying to accomplish,
I can immediately think of 7 ways:

        1: ensure adequate group permissions on the files and assign
           jdoe to the necessary group or supplemental group
        2: change the group ownership on the files in question and assign
           both ivan and jdoe to the new group or supplemental group
        3: set the permissions on the files to allow the necessary access
           to all users, thus including jdoe
        4: use 'sudo' or 'op' to give jdoe an euid shell of the owning
           user:group (ivan:moskau)
        5: give jdoe the password of the owning user (ivan)
        6: setup the appropriate RBAC roles and permissions to allow
           jdoe access to the files in question
        7: setup FACLs to give the jdoe the required access he needs to
           the particular set of files in question.

Of the above, there are also noted drawbacks.  Option 1 not only gives
jdoe access to the files he needs, but also any others accessible by group
moskau, more access than jdoe needs.  Option 2 is usable, though there
may be issues with applications or procedures that depend on the group
being moskau.  Additionally, if group moskau is the primary handler of
these files, not only ivan needs to be regiven access, but also group
moskau as well, adding additional work.  Option 3 works, but instead
of just giving jdoe access, every user on the system also has access to
these files, exposing data to anyone looking.  Option 4 would allow jdoe
a system shell as user ivan, allowing him to work as though he was user
ivan, a ridiculous amount of access and potential security implication.
Option 5 is a variant of 4, with the exception that option 4 may or may
not require jdoe to supply his own password to gain shell access as ivan.
Option 5 simply gives jdoe ivan's account password.  Aside from the
issues listed in option 4, a further problem exists when ivan's password
is changed, jdoe would need to be notified of the new password so that
he would still have access to the necessary files.  Option 6 will most
assuredly work and should allow you to retain existing permissions and
ownership over the specified files.  The drawback is that appropriately
setting up RBAC for a potentially one time situation is overkill and
can considerably increase the complexity of the situation.  Option 7
will allow you to retain the existing permissions and ownership of
the specified files, while also allowing jdoe the access he needs and
only the access he needs.  There are issues to 7, however, such as not
everyone is familiar with how to use or read FACLs (Filesystem Access
Control Lists).  Additionally, you may need to modify the underlying
filesystem attributes on which the files reside in order to use FACLs.
As is evident above, there are a variety of methods (and likely others)
to give jdoe the access he needs, though from that listed, only FACLs
provide the appropriate level of precision while retaining the sanity
of the environment.  While not giving every possible usage of FACLs,
the following is provided as an introduction to them.

HOST INFO

        Hosts:                  tux, beastie, snorkle
        Shell Prompt:           user@host [0]
        OSes:                   CentOS 5.4 (Linux), FreeBSD 8.1, Solaris 10
        Notes:                  FACLs have been around awhile and should
                                be available in any recent version of
                                CentOS, FreeBSD, and Solaris
        USER:GROUP pairs:       troy:sysvuser
                                calif:bsduser

DETAILS

Before continuing, full command sessions without discussion can be found
at the end in the 'EXAMPLES' section covering each OS listed above.
Additionally, the process and even the command sets are almost entirely
usable between the three OSes.  Deviation points will be mentioned in
this current setion (DETAILS), which uses a FreeBSD host for primary
examples, though the EXAMPLES section contains actual command syntax of
those deviations.

Following a similar vein to that of the INTRO, we need to give user
'calif' access to write file '/mnt/somevol/blah/showdisk/vxnotes'.
The file is currently owned by user:group 'troy:sysvuser'.  Below
identifies our current setup:

        calif@beastie [0] /usr/bin/whoami
        calif
        calif@beastie [0] /usr/bin/id -a
        uid=1001(calif) gid=1001(bsduser) groups=1001(bsduser)
        calif@beastie [0] /usr/bin/id -a troy
        uid=1000(troy) gid=1000(sysvuser) groups=1000(sysvuser)
        calif@beastie [0] /bin/ls -ld /mnt /mnt/somevol /mnt/somevol/blah /mnt/somevol/blah/showdisk
        drwxr-xr-x  7 root  wheel     512 Oct  7 01:54 /mnt/
        drwxr-xr-x  4 root  wheel     512 Oct  7 01:57 /mnt/somevol/
        drwxr-xr-x  3 troy  sysvuser  512 Oct  7 01:57 /mnt/somevol/blah/
        drwxr-xr-x  5 troy  sysvuser  512 Sep 28 10:56 /mnt/somevol/blah/showdisk/

So we currently are euid 'calif', of only the 'bsduser' group.  User
'troy' is a member of only the 'sysvuser' group, and the permissions of
'/mnt/somevol/blah/showdisk/' allow 'calif' to at least read and search
that directory.  Unfortunately, this doesn't necessarily give 'calif'
the access he needs to write 'vxnotes:

        calif@beastie [0] cd /mnt/somevol/blah/showdisk
        calif@beastie [0] /usr/bin/vi vxnotes
        # Error: vxnotes: Permission denied.
        calif@beastie [0] /bin/ls -l vxnotes
        -rw-r--r--  1 troy  sysvuser  4387 Sep 28 10:56 vxnotes

Above, 'calif' attempts to open 'vxnotes' for writing, though upon
attempt to save the file, 'vi' throws a "Permission denied" error.
A review of the file permissions show that only 'troy' has access to
write this file, though anyone can read it.  Upon opening 'vxnotes',
'vi' would have also issued a warning about the file being read-only.
To allow 'calif' the write access he needs, as 'root', we can setup a
FACL for 'vxnotes':

        root@beastie [0] /bin/setfacl -m u:calif:rw /mnt/somevol/blah/showdisk/vxnotes
        setfacl: vxnotes: acl_get_file() failed: Operation not supported

Well, that's an issue.  Our attempt as 'root' to setup a FACL failed.
This is due to needing FACLs enabled on the filesystem in question and the
kernel must support them.  For Solaris, Linux, and FreeBSD, the kernel is
compiled by default to handle FACLs.  So unless (under Linux and FreeBSD)
you have recompiled the kernel deliberately removing FACLs, there should
be no problem with the kernel.  Under Solaris, by default, filesystems are
setup to address FACLs, so you likely would never see the above failure.
Under Linux and FreeBSD, the underlying filesystem either needs to be
mounted with FACLs enabled or the FS attributes in the superblock need
to be modified to enable FACLs.  Time to remount a filesystem:

        root@beastie [0] /sbin/mount | grep somevol
        /dev/da1s1a on /mnt/somevol (ufs, local)
        root@beastie [0] /sbin/umount /mnt/somevol
        root@beastie [0] /sbin/mount -o rw,acls /dev/da1s1a /mnt/somevol
        root@beastie [0] /sbin/mount | /usr/bin/grep somevol        
        /dev/da1s1a on /mnt/somevol (ufs, local, acls)

In the above, a quick check of the mounted filesystems shows
'/mnt/somevol' available, though nothing about FACLs.  To enable them,
the filesystem must either be mounted read-only (useless for a write
FACL) or unmounted and remounted appropriately.  After the remount, we
can now see that FACLs are enabled.  As an alternative to remounting the
FS with the 'acls' mount option, mentioned earlier is that we can update
the superblock to enable FACLs.  The benefit is that you don't need to
update /etc/fstab and continually mount the FS specifying FACL support.
Instead, you umount the volume as listed above, and use 'tunefs'
(tune2fs under Linux) to permanent enable the FACLs:

        root@beastie [0] /sbin/tunefs -a enable /dev/da1s1a
        tunefs: POSIX.1e ACLs set
        root@beastie [0] /sbin/tunefs -p /dev/da1s1a 2>&1 | /usr/bin/grep 'POSIX.1e ACLs'
        tunefs: POSIX.1e ACLs: (-a)                                enabled
        root@beastie [0] /sbin/mount | /usr/bin/grep somevol
        /dev/da1s1a on /mnt/somevol (ufs, local, acls)

(Superblock adjustments are entirely unnecessary if you've already
mounted the volume with the 'acls' mount option.  The above is simply
an alternative means of enabling FACLs, though on a permanent basis
where simple mount options are only temporary.)  After '/mnt/somevol'
is unmounted, the first command will enable FACLs on 'da1s1a'.
The verification can be seen in the second command.  To further verify,
after '/dev/da1s1a' has been remounted, a check of the mount shows
FACLs enabled.  (Under Linux, after update of the superblock and after
remount of the filesystem, a check of the mount will not show whether
or not FACLs are enabled.  The second command is effectively your only
verification.) With that out of the way, we can now see that 'setfacl'
works:

        root@beastie [0] /bin/setfacl -m u:calif:rw /mnt/somevol/blah/showdisk/vxnotes
        root@beastie [0] /bin/ls -ld /mnt/somevol/blah/showdisk/vxnotes
        -rw-rw-r--+ 1 troy  sysvuser  4387 Sep 28 10:56 /mnt/somevol/blah/showdisk/vxnotes
        root@beastie [0] /bin/getfacl /mnt/somevol/blah/showdisk/vxnotes
        # file: /mnt/somevol/blah/showdisk/vxnotes
        # owner: troy
        # group: sysvuser
        user::rw-
        user:calif:rw-
        group::r--
        mask::rw-
        other::r--
        root@beastie [0]

After running 'setfacl', a long listing of the file shows a '+' at the
end of the permissions.  This is the standard way of illustrating there
are active FACLs in place on the file in question.  Using 'getfacl' will
display the configured FACLs; special note should be made of 'mask',
which sets the default allowable permissions of any FACL.  Our output
shows a mask of 'rw-', so the max effective permissions of any FACL
are 'read-write'.  Switching back to user 'calif', we can try writing
'vxnotes' agains:

        calif@beastie [0] cd /mnt/somevol/blah/showdisk
        calif@beastie [0] /usr/bin/head -1 vxnotes
        notes on VxVM devices
        calif@beastie [0] /usr/bin/vi vxnotes
        # vxnotes: 56 lines, 4408 characters.
        calif@beastie [0] /usr/bin/head -1 vxnotes
        # calif@beastie was here

A quick check of the file shows the first line before 'calif' edits it.
Upon attempt to save 'vxnotes', 'vi' notifies us that it was written
(vxnotes: 56 lines, 4408 characters. (or some variation of this line)).
On subsequent check of 'vxnotes', we see 'calif' was successful in
updating the file, and had replaced the first line.

Suppose instead, rather than just giving 'calif' access to write
'vxnotes', you want anyone in group 'bsduser' to be able to do so.
For this, as a matter of tidiness, we'll remove the FACL for user 'calif'
and follow up with a group FACL for group 'bsduser':

        root@beastie [0] /bin/setfacl -x u:calif:rw /mnt/somevol/blah/showdisk/vxnotes
        root@beastie [0] /bin/setfacl -m g:bsduser:rw /mnt/somevol/blah/showdisk/vxnotes
        root@beastie [0] /bin/getfacl /mnt/somevol/blah/showdisk/vxnotes
        # file: /mnt/somevol/blah/showdisk/vxnotes
        # owner: troy
        # group: sysvuser
        user::rw-
        group::r--
        group:bsduser:rw-
        mask::rw-
        other::r--
        root@beastie [0]

Still using 'calif' for our example, we can see that 'calif' can and
has updated 'vxnotes' again:

        calif@beastie [0] /usr/bin/vi vxnotes
        # vxnotes: 56 lines, 4425 characters.
        calif@beastie [0] /usr/bin/head -1 vxnotes
        # calif@beastie has left the building

I mentioned earlier to note the 'mask' entry in FACLs.  Below, 'root'
sets the FACL mask for vxnotes to read-only, stripping off write access:

        root@beastie [0] /bin/setfacl -m m::r /mnt/somevol/blah/showdisk/vxnotes
        root@beastie [0] /bin/getfacl /mnt/somevol/blah/showdisk/vxnotes
        # file: /mnt/somevol/blah/showdisk/vxnotes
        # owner: troy
        # group: sysvuser
        user::rw-
        group::r--
        group:bsduser:rw-               # effective: r--
        mask::r--
        other::r--
        root@beastie [0]

Even though we configured a FACL for group 'bsduser' giving read-write
access, we now see the effective permissions are read-only.  The FACL for
'bsduser' hasn't changed but the new mask will prohibit further writes:

        calif@beastie [0] /usr/bin/vi vxnotes
        # Error: vxnotes: Permission denied.

As point of warning, it should be noted that normal file permission
changes can have a direct impact on the FACLs and mask one has setup
on a file.  The following sets the permissions for group access for
'sysvuser' to read-write-execute.  This update also updates the FACL
'mask', as the mask is effectively no greater than that given to the
owning user, group, or other permissions:

        root@beastie [0] /bin/chmod 675 /mnt/somevol/blah/showdisk/vxnotes
        root@beastie [0] /bin/getfacl /mnt/somevol/blah/showdisk/vxnotes
        # file: /mnt/somevol/blah/showdisk/vxnotes
        # owner: troy
        # group: sysvuser
        user::rw-
        group::r--
        group:bsduser:rw-
        mask::rwx
        other::r-x

Subsequent to the above 'chmod', a user in group 'bsduser' once again
has write access to 'vxnotes'.  To remove that access, either the FACL
'mask' would again need to be updated removing the write access or the
FACL for group 'bsduser' needs to be adjusted or removed.

As an extension of normal file permissions, FACLs offer a means of
allowing particular file access to additional users and groups without
the heavy-handed means of other solutions while also limiting unnecessary
complexity.  A potential issue is the retention of configured FACLs if you
transfer the file(s) in question to another host of disparate OS type,
such as from Linux to FreeBSD, etc.  The problem arises if the other OS
doesn't understand or acknowledge FACLs set from the originiating host.
Depending on how the files are transferred, you may retain normal file
permissions though have to reset the FACLs you had in place.  For further
information on FACLs, check out the man pages for:

        setfacl         getfacl         chmod


EXAMPLES

# EXAMPLE - Linux Host
    calif@tux [0] /usr/bin/whoami
    calif
    calif@tux [0] /usr/bin/id -a
    uid=1001(calif) gid=1001(bsduser) groups=1001(bsduser)
    calif@tux [0] /usr/bin/id -a troy
    uid=1000(troy) gid=1000(sysvuser) groups=1000(sysvuser)
    calif@tux [0] /bin/ls -ld /mnt /mnt/somevol /mnt/somevol/blah /mnt/somevol/blah/showdisk
    drwxr-xr-x 9 root root     4096 Oct  3 02:35 /mnt/
    drwxr-xr-x 4 root root     1024 Oct  7 01:53 /mnt/somevol/
    drwxr-xr-x 3 troy sysvuser 1024 Oct  5 02:31 /mnt/somevol/blah/
    drwxr-xr-x 6 troy sysvuser 1024 Oct  5 02:52 /mnt/somevol/blah/showdisk/
    calif@tux [0] cd /mnt/somevol/blah/showdisk
    calif@tux [0] /bin/vi vxnotes
    # "vxnotes" E212: Can't open file for writing
    calif@tux [0] /bin/ls -l vxnotes
    -rw-r--r-- 1 troy sysvuser 4387 Sep 28 10:56 vxnotes
    root@tux [0] /usr/bin/setfacl -m u:calif:rw /mnt/somevol/blah/showdisk/vxnotes
    setfacl: vxnotes: Operation not supported
    root@tux [1] /bin/mount | grep somevol
    /dev/sdb1 on /mnt/somevol type ext3 (rw)
    root@tux [0] /bin/umount /mnt/somevol
    root@tux [0] /bin/mount -o rw,acl /dev/sdb1 /mnt/somevol
    root@tux [0] /bin/mount | grep somevol
    /dev/sdb1 on /mnt/somevol type ext3 (rw,acl)
    ### Alternatively, you can update the superblock of the unmounted filesystem
    ### to permanently enable FACLs
    # root@tux [0] /sbin/tune2fs -o acl /dev/sdb1
    # tune2fs 1.39 (29-May-2006)
    # root@tux [0] /bin/mount | /bin/grep somevol
    # /dev/sdb1 on /mnt/somevol type ext3 (rw)
    # root@tux [0] /sbin/tune2fs -l /dev/sdb1 | /bin/grep 'mount options'
    # Default mount options:    acl
    root@tux [0] /usr/bin/setfacl -m u:calif:rw /mnt/somevol/blah/showdisk/vxnotes
    root@tux [0] /bin/ls -ld /mnt/somevol/blah/showdisk/vxnotes
    -rw-rw-r--+ 1 troy sysvuser 4387 Sep 28 10:56 /mnt/somevol/blah/showdisk/vxnotes
    root@tux [0] /usr/bin/getfacl /mnt/somevol/blah/showdisk/vxnotes
    getfacl: Removing leading '/' from absolute path names
    # file: mnt/somevol/blah/showdisk/vxnotes
    # owner: troy
    # group: sysvuser
    user::rw-
    user:calif:rw-
    group::r--
    mask::rw-
    other::r--

    root@tux [0]
    calif@tux [0] cd /mnt/somevol/blah/showdisk
    calif@tux [0] /usr/bin/head -1 vxnotes
    notes on VxVM devices
    calif@tux [0] /bin/vi vxnotes
    # "vxnotes" 56L, 4408C written
    calif@tux [0] /usr/bin/head -1 vxnotes
    # calif@tux was here
    root@tux [0] /usr/bin/setfacl -x u:calif /mnt/somevol/blah/showdisk/vxnotes
    # does not accept exlicit POSIX removal of permissions (u:calif:rw)
    root@tux [0] /usr/bin/setfacl -m g:bsduser:rw /mnt/somevol/blah/showdisk/vxnotes
    root@tux [0] /usr/bin/getfacl /mnt/somevol/blah/showdisk/vxnotes
    getfacl: Removing leading '/' from absolute path names
    # file: mnt/somevol/blah/showdisk/vxnotes
    # owner: troy
    # group: sysvuser
    user::rw-
    group::r--
    group:bsduser:rw-
    mask::rw-
    other::r--

    root@tux [0]
    calif@tux [0] /bin/vi vxnotes
    "vxnotes" 56L, 4421C written
    calif@tux [0] /usr/bin/head -1 vxnotes
    # calif@tux has left the building
    root@tux [0] /usr/bin/setfacl -m m::r /mnt/somevol/blah/showdisk/vxnotes
    root@tux [0] /usr/bin/getfacl /mnt/somevol/blah/showdisk/vxnotes
    getfacl: Removing leading '/' from absolute path names
    # file: mnt/somevol/blah/showdisk/vxnotes
    # owner: troy
    # group: sysvuser
    user::rw-
    group::r--
    group:bsduser:rw-               #effective:r--
    mask::r--
    other::r--
   
    root@tux [0]
    calif@tux [0] /bin/vi vxnotes
    # "vxnotes" E212: Can't open file for writing
    root@tux [0] chmod 675 /mnt/somevol/blah/showdisk/vxnotes
    root@tux [0] /usr/bin/getfacl /mnt/somevol/blah/showdisk/vxnotes
    getfacl: Removing leading '/' from absolute path names
    # file: mnt/somevol/blah/showdisk/vxnotes
    # owner: troy
    # group: sysvuser
    user::rw-
    group::r--
    group:bsduser:rw-
    mask::rwx
    other::r-x
   
    root@tux [0]
   
# EXAMPLE - FreeBSD Host
    calif@beastie [0] /usr/bin/whoami
    calif
    calif@beastie [0] /usr/bin/id -a
    uid=1001(calif) gid=1001(bsduser) groups=1001(bsduser)
    calif@beastie [0] /usr/bin/id -a troy
    uid=1000(troy) gid=1000(sysvuser) groups=1000(sysvuser)
    calif@beastie [0] /bin/ls -ld /mnt /mnt/somevol /mnt/somevol/blah /mnt/somevol/blah/showdisk
    drwxr-xr-x  7 root  wheel     512 Oct  7 01:54 /mnt/
    drwxr-xr-x  4 root  wheel     512 Oct  7 01:57 /mnt/somevol/
    drwxr-xr-x  3 troy  sysvuser  512 Oct  7 01:57 /mnt/somevol/blah/
    drwxr-xr-x  5 troy  sysvuser  512 Sep 28 10:56 /mnt/somevol/blah/showdisk/
    calif@beastie [0] cd /mnt/somevol/blah/showdisk
    calif@beastie [0] /usr/bin/vi vxnotes
    # Error: vxnotes: Permission denied.
    calif@beastie [0] /bin/ls -l vxnotes
    -rw-r--r--  1 troy  sysvuser  4387 Sep 28 10:56 vxnotes
    root@beastie [0] /bin/setfacl -m u:calif:rw /mnt/somevol/blah/showdisk/vxnotes
    setfacl: vxnotes: acl_get_file() failed: Operation not supported
    root@beastie [0] /sbin/mount | grep somevol
    /dev/da1s1a on /mnt/somevol (ufs, local)
    root@beastie [0] /sbin/umount /mnt/somevol
    root@beastie [0] /sbin/mount -o rw,acls /dev/da1s1a /mnt/somevol
    root@beastie [0] /sbin/mount | /usr/bin/grep somevol
    /dev/da1s1a on /mnt/somevol (ufs, local, acls)
    ### Alternatively, you can update the superblock of the unmounted filesystem
    ### to permanently enable FACLs
    # root@beastie [0] /sbin/tunefs -a enable /dev/da1s1a
    # tunefs: POSIX.1e ACLs set
    # root@beastie [0] /sbin/tunefs -p /dev/da1s1a 2>&1 | /usr/bin/grep 'POSIX.1e ACLs'
    # tunefs: POSIX.1e ACLs: (-a)                                enabled
    # root@beastie [0] /sbin/mount | /usr/bin/grep somevol
    # /dev/da1s1a on /mnt/somevol (ufs, local, acls)

    root@beastie [0] /bin/setfacl -m u:calif:rw /mnt/somevol/blah/showdisk/vxnotes
    root@beastie [0] /bin/ls -ld /mnt/somevol/blah/showdisk/vxnotes
    -rw-rw-r--+ 1 troy  sysvuser  4387 Sep 28 10:56 /mnt/somevol/blah/showdisk/vxnotes
    root@beastie [0] /bin/getfacl /mnt/somevol/blah/showdisk/vxnotes
    # file: /mnt/somevol/blah/showdisk/vxnotes
    # owner: troy
    # group: sysvuser
    user::rw-
    user:calif:rw-
    group::r--
    mask::rw-
    other::r--
    root@beastie [0]
    calif@beastie [0] cd /mnt/somevol/blah/showdisk
    calif@beastie [0] /usr/bin/head -1 vxnotes
    notes on VxVM devices
    calif@beastie [0] /usr/bin/vi vxnotes
    # vxnotes: 56 lines, 4408 characters.
    calif@beastie [0] /usr/bin/head -1 vxnotes
    # calif@beastie was here
    root@beastie [0] /bin/setfacl -x u:calif:rw /mnt/somevol/blah/showdisk/vxnotes
    root@beastie [0] /bin/setfacl -m g:bsduser:rw /mnt/somevol/blah/showdisk/vxnotes
    root@beastie [0] /bin/getfacl /mnt/somevol/blah/showdisk/vxnotes
    # file: /mnt/somevol/blah/showdisk/vxnotes
    # owner: troy
    # group: sysvuser
    user::rw-
    group::r--
    group:bsduser:rw-
    mask::rw-
    other::r--
    root@beastie [0]
    calif@beastie [0] /usr/bin/vi vxnotes
    # vxnotes: 56 lines, 4425 characters.
    calif@beastie [0] /usr/bin/head -1 vxnotes
    # calif@beastie has left the building
    root@beastie [0] /bin/setfacl -m m::r /mnt/somevol/blah/showdisk/vxnotes
    root@beastie [0] /bin/getfacl /mnt/somevol/blah/showdisk/vxnotes
    # file: /mnt/somevol/blah/showdisk/vxnotes
    # owner: troy
    # group: sysvuser
    user::rw-
    group::r--
    group:bsduser:rw-               # effective: r--
    mask::r--
    other::r--
    root@beastie [0]
    calif@beastie [0] /usr/bin/vi vxnotes
    # Error: vxnotes: Permission denied.
    root@beastie [0] /bin/chmod 675 /mnt/somevol/blah/showdisk/vxnotes
    root@beastie [0] /bin/getfacl /mnt/somevol/blah/showdisk/vxnotes
    # file: /mnt/somevol/blah/showdisk/vxnotes
    # owner: troy
    # group: sysvuser
    user::rw-
    group::r--
    group:bsduser:rw-
    mask::rwx
    other::r-x

# EXAMPLE - Solaris Host
    calif@snorkle [0] /usr/ucb/whoami
    calif
    calif@snorkle [0] /usr/bin/id -a
    uid=1001(calif) gid=1001(bsduser) groups=1001(bsduser)
    calif@snorkle [0] /usr/bin/id -a troy
    uid=1000(troy) gid=1000(sysvuser) groups=1000(sysvuser)
    calif@snorkle [0] /usr/bin/ls -ld /mnt /mnt/somevol /mnt/somevol/blah /mnt/somevol/blah/showdisk
    drwxr-xr-x   7 root     sys          512 Oct  7 03:40 /mnt/
    drwxr-xr-x   4 root     root         512 Oct  7 03:44 /mnt/somevol/
    drwxr-xr-x   3 troy     sysvuser     512 Oct  7 03:44 /mnt/somevol/blah/
    drwxr-xr-x   3 troy     sysvuser     512 Oct  7 03:28 /mnt/somevol/blah/showdisk/
    calif@snorkle [0] cd /mnt/somevol/blah/showdisk
    calif@snorkle [0] /usr/bin/vi vxnotes
    # "vxnotes" Permission denied
    calif@snorkle [1] /usr/bin/ls -l vxnotes
    -rw-r--r--   1 troy     sysvuser    4387 Oct  7 03:28 vxnotes
    root@snorkle [0] /usr/bin/setfacl -m u:calif:rw- /mnt/somevol/blah/showdisk/vxnotes
    # solaris requires full permissions 'rw- rather than 'rw'
    root@snorkle [0] /usr/sbin/mount | /usr/bin/grep somevol
    /mnt/somevol on /dev/dsk/c1t2d0s0 read/write/setuid/devices/intr/largefiles/logging/xattr/onerror=panic/dev=800080 on Thu Oct  7 03:40:14 2010
    root@snorkle [0] /usr/bin/ls -ld /mnt/somevol/blah/showdisk/vxnotes
    -rw-r--r--+  1 troy     sysvuser    4387 Oct  7 03:28 /mnt/somevol/blah/showdisk/vxnotes
    root@snorkle [0] /usr/bin/getfacl /mnt/somevol/blah/showdisk/vxnotes
   
    # file: /mnt/somevol/blah/showdisk/vxnotes
    # owner: troy
    # group: sysvuser
    user::rw-
    user:calif:rw-          #effective:r--
    group::r--              #effective:r--
    mask:r--
    other:r--
    root@snorkle [0] /usr/bin/setfacl -m m:rw- /mnt/somevol/blah/showdisk/vxnotes
    # solaris only needs a single ":" when setting mask attributes
    root@snorkle [0] /usr/bin/getfacl /mnt/somevol/blah/showdisk/vxnotes
   
    # file: /mnt/somevol/blah/showdisk/vxnotes
    # owner: troy
    # group: sysvuser
    user::rw-
    user:calif:rw-          #effective:rw-
    group::r--              #effective:r--
    mask:rw-
    other:r--
    root@snorkle [0]
    calif@snorkle [0] /usr/bin/head -1 vxnotes
    notes on VxVM devices
    calif@snorkle [0] /usr/bin/vi vxnotes
    # "vxnotes" 56 lines, 4412 characters
    calif@snorkle [0] /usr/bin/head -1 vxnotes
    # calif@snorkle was here
    root@snorkle [0] /usr/bin/setfacl -d u:calif /mnt/somevol/blah/showdisk/vxnotes
    # FACL can be removed with or without specifying permissions
    root@snorkle [0] /usr/bin/setfacl -r -m g:bsduser:rw- /mnt/somevol/blah/showdisk/vxnotes
    # under solaris -r recalculates necessary mask and updates accordingly
    # by default, modifying a FACL will update the FACL mask as necessary
    # under Linux and FreeBSD
    root@snorkle [0] /usr/bin/getfacl /mnt/somevol/blah/showdisk/vxnotes
    # file: /mnt/somevol/blah/showdisk/vxnotes
    # owner: troy
    # group: sysvuser
    user::rw-
    group::r--              #effective:r--
    group:bsduser:rw-               #effective:rw-
    mask:rw-
    other:r--
    root@snorkle [0]
    calif@snorkle [0] /usr/bin/vi vxnotes
    # "vxnotes" 56 lines, 4425 characters
    calif@snorkle [0] /usr/bin/head -1 vxnotes
    # calif@snorkle has left the building
    root@snorkle [0] /usr/bin/setfacl -m m:r-- /mnt/somevol/blah/showdisk/vxnotes
    root@snorkle [0] /usr/bin/getfacl /mnt/somevol/blah/showdisk/vxnotes

    # file: /mnt/somevol/blah/showdisk/vxnotes
    # owner: troy
    # group: sysvuser
    user::rw-
    group::r--              #effective:r--
    group:bsduser:rw-               #effective:r--
    mask:r--
    other:r--
    root@snorkle [0]
    calif@snorkle [0] /usr/bin/vi vxnotes
    # "vxnotes" Permission denied
    root@snorkle [0] /usr/bin/chmod 675 /mnt/somevol/blah/showdisk/vxnotes
    root@snorkle [0] /usr/bin/getfacl /mnt/somevol/blah/showdisk/vxnotes

    # file: /mnt/somevol/blah/showdisk/vxnotes
    # owner: troy
    # group: sysvuser
    user::rw-
    group::rwx              #effective:rwx
    group:bsduser:rw-               #effective:rw-
    mask:rwx
    other:r-x

No comments: