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:
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
