Softpanorama (slightly skeptical) Open Source Software Educational Society

May the source be with you, but remember the KISS principle ;-)

Solaris ACLs

Introduced in Solaris 2.5, ACLs are additional sets of read/write/execute triplets (rwx) that can be added on to files, directories, devices, or any other file system objects on per user or per group basis. 

They exist in a separate universe from Unix regular permissions and are not displayed by default by commands such as ls (but ls indicates whether they are present or not).   In essence this is an extension of a Unix group mechanism (multiple groups, each with a separate permissions set can be assigned to a file). In this case of assigning access to a particular user can be viewed as assignment of permission to a group with just one member (trivial group). 

As inability to assign files to multiple groups was a serious drawback of Unix from day 1, an ACL can enhance  file security by enabling you to define file permissions for additional groups. For directories it also enables you to define default permissions.

ACL behaves differently for files and directories (only directories have additional so called "default permissions").

The Solaris 9 ACL facility is compliant with the POSIX 1003.6 specification.  Interoperation with other platforms is limited: Linux has weak implementation with many utilities (for example tar) which are "ACL-blind", HP-US and AIX both have slightly different implementations.

Solaris 9 implementation works with the Solaris UFS as well as with Solaris NFS version 2 and 3. In case of NFS the ACLs will only work under Solaris NFS server. So for networked filesystems, both the NFS server and the client must be running Solaris.

ACLs generally breaks GNU utilities so for files with ACL the results produced by GNU coreutils ported to Solaris 9 (GNU ls, etc) cannot be trusted in Solaris.

While ACL are file based they are essentially user-oriented: For each file you can define a list of additional users (pseudo-owners) and groups (pseudo-groups) that will have a certain level of access: read, write, or execute access permissions

ACLs grant "higher-level" access rights that have priority over regular file permissions.

Solaris 9 implementation is based on the concept of shadow inodes: when you create an ACL, the existing inode points to a newly allocated inode called a shadow inode. When a specific ACL entry is placed on the  ACL list, the shadow inode contains a pointer to a data block containing  the list of ACL entries. That permits utilities that does not understand ACLs work correctly with files that have ACLs set. In this case, for example when you are using gnu tar instead of Solaris tar, they will strip all your ACL information.

You can use the ls -l command to see which files or directories have an ACL entry. If a file has an ACL entry, a plus (+) sign appears at the end of the permission field.

There are two separate commands for working with ACLsy:

• setfacl permits setting a file's ACLs
• getfacl permits  reading them.

Running getfacl on a normal file provides mapping of regular permissions to ACL world:

% cd /usr/tmp
% touch foo
% ls -l foo
-rw-r--r--   1 pbg      staff          0 Jul 22 13:35 foo

% getfacl foo
# file: foo
# owner: pbg
# group: staff
user::rw-
group::r--              #effective:r--
mask:rwx
other:r--

The user, group and other information is a straightforward display of the permission bits for those fields.

It is also important to note that ACLs "stick" to a file during copy and rename operations that are performed using regular Solaris commands like cp and mv. To remove the ACL from a file use setfacl -d for each entry. When the last entry is removed, the "+" disappears from the file's ls display.

Setting ACLs for the user

To set an ACL for a file, use the command setfacl:

% setfacl -m user:jeff:rw- foo

% ls -l foo
-rw-r--r--+  1 pbg      staff          0 Jul 22 13:52 foo

% getfacl foo

# file: foo
# owner: pbg
# group: staff
user::rw-
user:jeff:rw-           #effective:r--
group::r--              #effective:r--
mask:r--
other:r--

The -m option tells setfacl that I want to modify the ACLs for the file. You can specify only those attributes that you need to change. It looks like man page statement "When using the -m option to modify a default ACL, you must specify a complete default ACL (user, group, other, mask, and any additional entries) the first time" is incorrect:

 -m acl_entries

Adds one or more new ACL entries to the file, and/or modifies one or more existing ACL entries on the file. If an entry already exists for a specified uid or gid, the specified permissions will replace the current permissions. If an entry does not exist for the specified uid or gid, an entry will be created. When using the -m option to modify a default ACL, you must specify a complete default ACL (user, group, other, mask, and any additional entries) the first time.

Use the -s option to set the entire mode, but then you must type in the user, group, and other access bits as well:

% setfacl -s user::rw-,group::r--,other:---,mask:rw-,user:jeff:rw- foo

To set general user, group, and other permissions, use the field::perms identifier. To set ACLs for individual users and groups, use the field:uid or gid:perms identifier.

But back to our previous example. Notice that the effective access for user Jeff is unchanged, he can still only read the file, not write to it. That's the result of the mask being applied to his permissions. To grant Jeff the access desired, I need to:

% setfacl -m mask:rw- foo
% getfacl foo

# file: foo
# owner: pbg
# group: staff
user::rw-
user:jeff:rw-           #effective:rw-
group::r--              #effective:r--
mask:rw-
other:r--

Now Jeff has read and write permissions to the file, while all others have only read access. Of note is the slight change in behavior of the ls command. Any file with specific ACL information is shown with a + at the end of the permission field. Unfortunately, find doesn't seem to have an option to find all files with ACL lists.

By now, your warning bells are probably going off.  A hacker, having broken into your system, could use the ACL facility to create back doors. These back doors are very difficult to spot -- only inspection of ls output will identify the target files.

Fortunately, the programming interface to Solaris ACLs allows the creation of utilities to search for files with access control lists. See Module Documentation - SolarisACL 0.06 -- Perl module for Access of Solaris ACLs

Using the ACL facility on a directory adds some new twists. As well as setting an ACL for the directory, you can set a default ACL for the directory. This default ACL is used to set the ACL on every file created within the directory. The only way I managed to get directory ACLs to work was using the -s option with a very-long parameter string:

% setfacl -s user::rwx,group::rw-,mask:r--,other:rw-,default:user::rw-,\
default:group::r-x,default:mask:rwx,default:other:r-x bar

% ls -ld bar
drwxr--rw-+  2 pbg      staff        512 Jul 22 14:11 bar

% getfacl bar

# file: bar
# owner: pbg
# group: staff
user::rwx
group::rw-              #effective:r--
mask:r--
other:rw-
default:user::rw-
default:group::r-x
default:mask:rwx
default:other:r-x

Note:

I found that the FIRST time default ACLs are set, all of user, group, other and mask defaults must be set. This means that the first setfacl for a directory could be for instance:

$ setfacl -m d:u::rwx,d:o:---,d:g::---,d:m:rwx facltest/

Once these four default ACLs have been set, subsequent "normal" calls to setfacl can be made, such as:

$ setfacl -m default:user:myself:rwx facltest/

Now set a default ACL, and create a file in the directory:

% setfacl -m default:user:jeff:rwx bar

% getfacl bar

# file: bar
# owner: pbg
# group: staff
user::rwx
group::rw-              #effective:r--
mask:r--
other:rw-
default:user::rw-
default:user:jeff:rwx
default:group::r-x
default:mask:rwx
default:other:r-x
default:user::rw-
default:user:jeff:rwx
default:group::r-x
default:mask:rwx
default:other:r-x

% touch bar/test

% getfacl bar/test

# file: bar/test
# owner: pbg
# group: staff
user::rw-
user:jeff:rwx           #effective:r--
group::r--              #effective:r--
mask:r--
other:r--

There are several other aspects of ACLs, including deleting ACLs and using abbreviations and permission bit numbers (rather than symbols). This information is provided on the appropriate manual pages. You'll get a similar error if you try to use ACLs in a swapfs-based directory (such as /tmp). Finally, there's a "non-feature" of ACLs when used with  Solaris tar.  Solaris tar itself works well with files that have associated ACLs. Unfortunately, the tar file is not always readable under other OSes.  You might be better off using GNU tar instead.

ACL Permissions for Directories

You can set default ACL entries on a directory that apply to files subsequently created within the directories. Files created in a directory that has default ACL entries will have the same ACL entries as the directory. When you set default ACL entries for specific users and groups on a directory for the first time, you must also set default ACL entries for the owner, owner's group, others, and the mask.

•  d[efault]:u[ser]::<perm> Sets the default permissions for the owner of the directory.

•  d[efault]:g[roup]::<perm> Sets the default permissions for the owner's group.

•  d[efault]:o[ther]::<perm> Sets the default permissions for users other than the owner or members of the owner's group.

•  d[efault]:m[ask]::<perm> Sets the default ACL mask.

•  d[efault]:u[ser]:<UID>:<perm> Sets the default permissions for a specific user.

•  d[efault]:g[roup]:<GID>:<perm> Sets the default permissions for a specific group.

Old News ;-)

[Aug 2, 2006] Softpanorama feedback

Thank you for valuable information about ACLs on your webpage! Thanks to you I found exactly what I was looking for, which was default ACLs on new files in a directory. I did however also find a small "error" on the page http://www.softpanorama.org/Solaris/ACL/index.shtml. In the paragraph starting with "Using the ACL facility on a directory adds some new twists", it says that setting the entire ACL is the only way you have been able to make it work. By reading the setfacl man page carefully, I found that the FIRST time default ACLs are set, all of user, group, other and mask defaults must be set. This means that the first setfacl for a directory could be for instance:

$ setfacl -m d:u::rwx,d:o:---,d:g::---,d:m:rwx facltest/

Once these four default ACLs have been set, subsequent "normal" calls to setfacl can be made, such as:

$ setfacl -m default:user:myself:rwx facltest/

Best regards, Boye

Module Documentation - SolarisACL 0.06

Perl module for Access of Solaris ACLs

something or another… » lsacl - Solaris ACL’s for mere mortals.

The classical user/group/everyone file permissions that the UNIX world has been used to the last 30 years, is pretty much an assumed. Nowadays, however, many UNIX implementations allow for granular file access control lists. Most UNIX administrator's still avoid them because they are not as apparent to them when doing a file listing.

I decided to be different. I wrote a tool to enhance the standard "ls" command into displaying file ACL's.

The absence of an easy way to see file permissions is one of the reasons why Windows Administrators tend to use ACL's more than UNIX ones. Windows Administrator's also tend to view and audit their file permissions much much less than UNIX administrator's. It's hidden away in several menu's, whereas they are always in your face when displaying files in UNIX.

Other than messing around on AIX in 1994, I had managed to avoid file ACL's under UNIX up until last year when we consolidated half a dozen HP servers to a Sun Cluster at work. Suddenly, permissions got complex. I don't really mean that complex, but on the HP's we used to have world writeable directories! HERR GUD!

So, when we sat down to implement file permissions on the Sun side, and got much whining from the DBA's and System Administrator's on the fact that we needed to use ACL's, I decided to make life easier for them.

I wrote this tool for Solaris, written in ruby named lsacl. It wraps around the ls command, and when it detects an ACL, runs getfacl and fakes it's own ls lines to go along with it. Because it wraps around ls, you can actually set an alias for ls to always run lsacl.

Here is what normal ls looks like:

% /bin/ls -lad samba 
drwxrwxr-x+  2 oracle   blahuser      96 May  6 14:52 samba

and the getfacl output for that directory:

% getfacl samba
# file: samba
# owner: oracle
# group: blahuser
user::rwx
group::rwx              #effective:rwx
group:blahsmb:rwx               #effective:rwx
mask:rwx
other:r-x
default:user::rw-
default:user:oracle:rw-
default:group::---
default:mask:rw-
default:other:---

Rather than depending on the user to figure all of that out however, lsacl makes it easy. My ls is aliased to it, so for me it's just:

% lsacl -lad samba
drwxrwxr-x+  2 oracle   blahuser      96 May  6 14:52 samba
A---rwxr-x+  2 -        blahsmb      ACL May  6 14:52 samba

Isn't that pleasant? The file ACL's in our cluster are now accessible by normal users. Our DBA's are no longer scared. We can now run permissions comparison's on different instances by just diffing the output of lsacl, rather than ls and praying the ACL's are the same.

We've been using this script for about a year here, I just made some cosmetic changes to it today and thought I'd let the world see it. Feel free to download lsacl, edit it, redistribute it, whatever. It requires ruby to be installed, and probably only works with Solaris, as I don't know how ls outputs ACL's on other UNIX implementations.

POSIX_ACLs_shells

Minimizing Host Exploitation by Reducing Access to "Popular" Executables by Use of POSIX ACL's Limited Publishing: 02/25/2003

Overview

This document provides a solution to reduce the effectiveness of most buffer overrun exploits by preventing the effective user id of the compromised process from accessing a shell or other "popular" process from which to pursue his/her attack. This is an extremely simple technique utilizing POSIX ACL's (Access Control Lists) and does not introduce any additional load on a modern OS.

Credits

Concept: Kristofer Spinka (kspinka@style.net) Proof of Concept: TBD

Concept

This works as is on Linux and Solaris, however RedHat temporarily removed support for getxattr()/setxattr() which actually implements "setfacl -m"; I think they had a stability problem. It works as expected on Solaris, but of course, it's Solaris. If you encounter non-standard limitations on other platforms, please provide feedback.

1. First make a dummy shell for testing and verification

    vi shell.c:
   -----------
   #include <unistd.h>
   
   int
   main(int argc, char *argv[])
   {
         write(1, "shell started!\n", 15);
         return 1;
   }
   -----------
       gcc -o shell shell.c
   

2. Create a "web server user" for testing. This is only temporary, we will remove it after testing.

        become root
        groupadd -g 57470 facltest
        useradd -c "setfacl test account" -d /tmp/facltest -g facltest -s /bin/bash -m -u 57470 facltest
        passwd facltest (set a password for the account)
        drop root
        

3. Execute setfacl -m u:facltest:--- shell

   This will remove all permissions for user "nobody" from the file "shell".
    

4. su - facltest attempt to execute "shell" created in step 1
    
5. Cleanup test environment. userdel -r facltest groupdel facltest
    
6. Apply facl's to all shells or other "popular" executables on your system for the account used to run network servies one by one, for example:

        setfacl -m u:nobody:--- /bin/ash
        setfacl -m u:nobody:--- /bin/bash
        setfacl -m u:nobody:--- /bin/csh
        setfacl -m u:nobody:--- /bin/sh
        setfacl -m u:nobody:--- /usr/bin/es
        setfacl -m u:nobody:--- /usr/bin/ksh
        setfacl -m u:nobody:--- /bin/ksh
        setfacl -m u:nobody:--- /usr/bin/rc
        setfacl -m u:nobody:--- /usr/bin/tcsh
        setfacl -m u:nobody:--- /bin/tcsh
        setfacl -m u:nobody:--- /usr/bin/zsh
        setfacl -m u:nobody:--- /bin/sash
        setfacl -m u:nobody:--- /bin/zsh
        setfacl -m u:nobody:--- /usr/bin/esh
        setfacl -m u:nobody:--- /bin/dash
   

   You should repeat this for *all* user accounts that run your network services, for example, the user account that httpd runs as, the user account named runs as, the user account sendmail runs as, etc.

ACL Interactions With Microsoft

Microsoft Windows has its own version of access control lists. When PC users Citrix MetaFrame users write files from Windows to the BCG storage server via samba, the Microsoft ACL associated with a file is translated to a Unix ACL. Sometimes this is done only by setting the standard Unix permissions.

In other cases, the Solaris ACL system described above is used. An ACL is usually set when a file's  "Properties->Security"  menu is modified. For example, if you grant another user access to a file through Windows, you'll find a '+' sign on the permissions when you list it from Solaris. You can remove the ACL with  rmacl  command described above, but then the user to whom you granted access from Windows will no longer be able to access the file.

Recommended Links

docs.sun.com: System Administration Guide: Solaris 10 Security Services

Using Solaris ACLs

DecisionACL - Manage and Build Access Control Lists

POSIX Access Control Lists on Linux

Solaris Advanced System Administrator's Guide, Second EditionUnderstanding System Security

GNU cfengine - Solaris ACLs

Using dtfile for viewing ACLs

The dtfile file manager provides an easy, graphical interface to managing Solaris ACLs. Under the Selected-Properties menu there is a button to "Show Access Control List". Here permissions for a particular user or group can be added to or removed from a file. The program makes sure the mask setting is correct to give the intended permissions. This program is part of the CDE desktop environment. It can be launched form the command line via:

docs.sun.com Trusted Solaris User's Guide/Setting Permissions and Access Control Lists

To Display the Properties Dialog Box for a File or Folder

To View the Basic Information of a File or Folder

To View or Change a File or Folder's Basic Permissions

To View a File or Folder's ACL Entries

To Add an ACL Entry

To Change an ACL Entry

To Delete an ACL Entry

Internals

Controlling permissions with ACLs - SunWorld - June 1998

The kernel implementation of ACLs requires a means of storing the ACLs on disk, as well as an incore representation for opened files. The linkage to a file's ACLS begins with the inode. A pointer, i_shadow, is defined in the file's inode and is set as a pointer to a shadow inode when an ACL is created for a file. The shadow inode is not a special type of inode; it is not defined by a specific shadow inode data structure. Rather, it is a generic UFS inode used for a special purpose -- that purpose being to provide a means of storing file ACL information on disk.

The representation of file ACLs in memory involves several data structures that are rooted at the memory resident inode for the file, in a pointer called i_ufs_acl. The i_ufs_acl pointer references a data structure that represents a memory resident shadow inode, the si structure. There are many fields in a generic UFS inode that are not required when the inode is used as a shadow inode, so it does not make sense to cache an entire inode in memory when it is a shadow inode. The si structure defines the shadow inode fields that are of use in the implementation of ACLs.

There is further linkage of additional kernel data structures from the si structure that are used by the kernel for ACLs. Reference Figure 1 for the complete picture.

 

The incore shadow inode structure contains various fields that the kernel uses for its implementation of ACLs. The s_signature field is used to store a unique signature for the ACL. The signature is generated when ACLs are first created for a file, and a shadow inode must be retrieved or allocated from the cache (see below). The signature is simply a checksum of the various ACL objects (users, groups, etc.) that exist for the file and provide an easy way for the kernel to locate an ACL in the shadow inode cache when it invokes a search. Other fields in the incore shadow inode are similar to other kernel data structures we've looked at in past columns -- we have a reference count (s_ref), a flag field (s_flag), and a lock for protection against unsynchronized, concurrent access (s_lock).

The remaining structures linked to and from the incore shadow inode are the ic_acl (incore acl) and ufs_ic_acl structures, in which the actual ACL objects are stored. As per Figure 1, the incore shadow inode contains two ic_acl structures: one for the ACLs (s_a) and one for the default ACLs (s_d), if any exist. Each ic_acl structure entry is actually a pointer to a ufs_ic_acl, of which there is one for the owner, group, other, and each user and group for which a specific ACL entry has been created.

The kernel does a couple optimizations in its ACL implementation. First, shadow inodes are cached in memory. Second, shadow inodes are shared when appropriate. This means that a group of files that have the same owner and the same ACLs defined for every file will reference the same shadow inode for the storage and retrieval of the ACL objects in each file. This would be the case, for example, if a default ACL were defined by a user for a directory, and files started being added to that directory. Every file with the same owner would have the same ACL unless explicitly changed via setfacl(1)).

This system uses kernel memory more effectively, as we're not replicating the same kind of information (i.e., ACLs) in the kernel. Utilization of file system resources is also minimized this way: As long as the file has the same owner and the ACLs defined are identical the kernel doesn't have to allocate a shadow inode for every file that has an ACL (resulting in the same signature, as above).

A couple of counters are maintained by the kernel for maintaining shadow inode cache hits and misses: si_cachehit and si_cachemiss. I am not aware of any bundled shell command that makes this information available, but it can be examined using adb(1) as follows.

 

# adb -k /dev/ksyms /dev/mem	** note you must be root, type this to invoke adb 
physmem fdde			** adb returns this when invoked
si_cachehit/D			** type this. 
si_cachehit:			** adb returned this
si_cachehit:    2187		** adb returned this
				** type carriage return here
si_cachemiss:			** adb returned this
si_cachemiss:   13		** adb returned this

$q				** type this to exit adb

# 

You can do some quick arithmetic to calculate your ACL cache hit rate: 2187 + 13 = 2200 cache references. 2187 / 2200 * 100 = 99.41, thus our example shows a 99.41 percent cache hit rate. The shadow inode (ACL) cache is not tunable. There are no kernel variables that can be set in the /etc/system file in increase or decrease the shadow inode cache.

When an ACL is created for a file, the kernel first searches the shadow inode cache to see if a resident shadow inode exists that could be used, based on the shadow inode signature. In the case of a cache hit, the pointer linkage is done, and the reference count for the shadow inode (s_ref) is incremented. If no shadow inode exists, the kernel calls the same ufs_ialloc() (allocate a UFS inode) routine that's used for allocating inodes for newly created files. Once the inode is allocated, the i_shadow pointer in the file's original inode is set to point to it, and the i_mode field in the newly allocated shadow inode is set to IFSHAD, indicating that this inode is a shadow inode.

ACL information and access is linked to the vnode layer, such that the kernel can provide a generic set of file system interfaces to access ACL data, keeping the VFS/Vnode layer consistent with its original design intention (see earlier columns for more information on vnodes). The system defines VOP_GETSECATTR and VOP_SETSECATTR operations (get_secondary_attributes and set_secondary_attributes) for accessing file ACL information through the standard VFS/Vnode interface. A data structure for this purpose is defined in vnode.h, the vsecattr structure, which, when initialized, will point to the ACL entries and default ACL entries for the file that the vnode is allocated to. The kernel actually checks for the existence of VOP_GETSECATTR and VOP_SETSECATTR in the vfs operations structure for a file system to determine if a particular file system supports ACLs.

On disk, the ACLs are stored the same way as file data is, referenced through the direct and indirect block pointers in the inode. Thus, the blocks pointed to by the shadow inode's i_db[] array will hold the actual ACL objects. The kernel defines a maximum of number of ACL entries that can be created per file of 1024 (1k). Given that each ACL entry only occupies 12 bytes, the actual storage of ACLs on disk typically does not require very much space, although a lot of files with a large number of unique ACL entries per file could add up (and that's not even counting inode allocation). If you're looking at a file system and trying to account for used data blocks and inodes, don't forget to consider ACL use.

That's a wrap for this month. Next month we'll cover large files in Solaris.

Modification of ls to display ACL "in-line"

something or another… » lsacl - Solaris ACL’s for mere mortals.

The classical user/group/everyone file permissions that the UNIX world has been used to the last 30 years, is pretty much an assumed. Nowadays, however, many UNIX implementations allow for granular file access control lists. Most UNIX administrator’s still avoid them because they are not as apparent to them when doing a file listing.

I decided to be different. I wrote a tool to enhance the standard “ls” command into displaying file ACL’s.

The absence of an easy way to see file permissions is one of the reasons why Windows Administrators tend to use ACL’s more than UNIX ones. Windows Administrator’s also tend to view and audit their file permissions much much less than UNIX administrator’s. It’s hidden away in several menu’s, whereas they are always in your face when displaying files in UNIX.

Other than messing around on AIX in 1994, I had managed to avoid file ACL’s under UNIX up until last year when we consolidated half a dozen HP servers to a Sun Cluster at work. Suddenly, permissions got complex. I don’t really mean that complex, but on the HP’s we used to have world writeable directories! HERR GUD!

So, when we sat down to implement file permissions on the Sun side, and got much whining from the DBA’s and System Administrator’s on the fact that we needed to use ACL’s, I decided to make life easier for them.

I wrote this tool for Solaris, written in ruby named lsacl. It wraps around the ls command, and when it detects an ACL, runs getfacl and fakes it’s own ls lines to go along with it. Because it wraps around ls, you can actually set an alias for ls to always run lsacl.

Here is what normal ls looks like:

% /bin/ls -lad samba
drwxrwxr-x+  2 oracle   blahuser      96 May  6 14:52 samba

and the getfacl output for that directory:

% getfacl samba
# file: samba
# owner: oracle
# group: blahuser
user::rwx
group::rwx              #effective:rwx
group:blahsmb:rwx               #effective:rwx
mask:rwx
other:r-x
default:user::rw-
default:user:oracle:rw-
default:group::---
default:mask:rw-
default:other:---

Rather than depending on the user to figure all of that out however, lsacl makes it easy. My ls is aliased to it, so for me it’s just:

% lsacl -lad samba
drwxrwxr-x+  2 oracle   blahuser      96 May  6 14:52 samba
A---rwxr-x+  2 -        blahsmb      ACL May  6 14:52 samba

Isn’t that pleasant? The file ACL’s in our cluster are now accessible by normal users. Our DBA’s are no longer scared. We can now run permissions comparison’s on different instances by just diffing the output of lsacl, rather than ls and praying the ACL’s are the same.

We’ve been using this script for about a year here, I just made some cosmetic changes to it today and thought I’d let the world see it. Feel free to download lsacl, edit it, redistribute it, whatever. It requires ruby to be installed, and probably only works with Solaris, as I don’t know how ls outputs ACL’s on other UNIX implementations.

Perl interface

Module Documentation - SolarisACL 0.06 Solaris::ACL - Perl extension for reading and setting Solaris Access Control Lists for files

  use Solaris::ACL;
  ($acl, $default_acl) = getfacl("path/to/file");
  setfacl("path/to/file", $acl [, $default_acl]);

This module provides access to the system level acl(2) call, allowing efficient setting and reading of Access Control Lists (ACLs) in perl.

ACL provides the following functions:

setfacl($path, $acl [, $default_acl])

Set the ACL of the file or directory named by $path to that specified by $acl. If $path names a directory, then the optional $default_acl argument can also be passed to specify the default ACL for the directory. See "ACL structure" for information on how the $acl and $default_acl hashes should be constructed.
 

getfacl($file_name)

Return a reference to a hash containing information about the file's ACL. If the file is a directory with a default ACL, then a list is returned, with the first entry being a hash reference to the ACL, and the second being a hash reference to the default ACL. See "Accessing ACL structures" for information on how to access these hashes, and "ACL structure" for information on how these hashes are internally constructed.

The structures returned by the getfacl call are blessed into the Solaris::ACL package, and can be inspected and changed using methods from that class. In most cases, the same method can be used for inspecting or setting values; a value is set if data is given to set it with; otherwise, it is inspected and returned. The following accessor methods are defined:

uperm

 

gperm

 

operm

 

mask

Without an argument, each of these methods returns the permission for the corresponding entity (user, group, other, or file mask). With an argument, they set the permission to that argument. For example:

  $user_perm = $acl->uperm;  # find out current owner permissions.
  $acl->operm(5);            # give others read-execute permissions.

If no mask is set in the ACL, mask returns -1.

users

 

groups

Without arguments, return a list of users (by uid) or groups (by gid) with special ACL access. When passed a uid/gid as an argument, return the permission for the given user/group, or -1 if no permission is set in the ACL. When passed a uid/gid and a permission, give the specified user/group the indicated permission; if the permission is -1, remove any permissions for the specified user/group.

calc_mask

Calculate the mask for the acl, as would the -r flag of setfacl.

equal($acl2)

Check to see if the acl is equal to $acl2. Returns 1 if equal, 0 otherwise.

Solaris::ACL->new($mode)

Create a new blessed acl with permissions for user, group and other determined by mode.

EXAMPLES

  $acl = new Solaris::ACL(0741);
  $acl->users(scalar(getpwnam("iroberts"),2);
  $acl->users(scalar(getpwnam("rdb"),0);
  $acl->calc_mask;

  $def_acl = new Solaris::ACL(0751);

  setfacl("working_dir", $acl, $def_acl);

  ($acl1, $def_acl1) = getfacl("working_dir");

  print "All is well\n" if($acl->equal($acl1));

  $acl2 = getfacl("working_file");
  print "uids with acls set: ", join(", ", $acl2->users), "\n";
  print "uid 29 had permission ", $acl2->users(29), "\n";
  $acl2->users(29,6);
  $acl2->calc_mask;
  setfacl("working_file", $acl2)
  print "uid 29 now has permission 6\n";

  # to copy an acl from one file or directory to another;
  setfacl($target_file, getfacl($source_file));

RETURN VALUES

setfacl returns TRUE if successful and FALSE if unsuccessful. getfacl, if successful, returns a list containing a reference to the hash describing an acl, and, if there is a default acl, a reference to the hash describing the default acl. If unsuccessful, getfacl returns a null list. If either setfacl or getfacl are unsuccessful, the variable $Solaris::ACL::error is set to a descriptive error string; in addition, if the failure was due to a system error, $! is set.

ACL structure

WARNING: The internal structures described here are subject to change in future versions.

All information passed to setfacl returned from getfacl is in the form of references to hashes. A hash describing an ACL can have the following keys:

uperm, gperm, operm, mask

Each of these keys have values containing permissions for the corresponding entity (user, group, other, mask).

groups, users

Each of these keys (if existent) contain a reference to a hash whose keys are decimal representations of numbers, and whose values contain permissions for the user/group whose uid/gid is the number in the key.

BUGS

No checking is done on data types; bad data will result in strange error message being placed in $Solaris::ACL::errors.

AUTHOR

Ian Robertson <ian@lugh.uchicago.edu>

Etc

Solaris ACLs

Under Solaris, the ACL type can be one of the following:

        user
        group
        mask
        other

For directories only
        default_user
        default_group
        default_mask
        default_other

A user or group can be specified to the user, group, default_user and default_group types. Solaris ACL permissions are the normal UNIX permissions bits `rwx', where:

    
        r - Grants read privileges.
        w - Grants write privileges.
        x - Grants execute privileges.

Last modified: July 01, 2008