SDB:POSIX Access Control List (ACL) Support

Version: 8.1

For the first time, SuSE Linux 8.1 contains experimental support for POSIX Access Control Lists (ACLs). This article describes what documentation on ACLs is available, how they can be activated, and what to keep in mind when using them.

Introduction

POSIX Access Control Lists are an extension of the traditional UNIX permission scheme. They are used to assign permissions to specified users and groups other than the file owner, owning group, and others. It is also possible to define, per directory, which permissions newly created files should have.

Access Control Lists are an experimental feature of SuSE Linux 8.1. As they are a very recent development, we are expecting to release update packages. Make sure you are running up-to-date kernels and packages. The YaST2 chapter in the Users Manual describes the necessary steps for obtaining updates.

Supported File Systems

SuSE Linux 8.1 supports ACLs on the ext2 and ext3 file systems. ACL support is also present in xfs and jfs, but using ACLs with either xfs or jfs is not recommended at this point, because there are known issues on both file systems. ACL support on reiserfs is also forthcoming, but the necessary code is not activated in the kernel released with SuSE Linux 8.1. After all file systems have passed our internal ACL tests, we will release an updated kernel for SuSE Linux 8.1.

Activating ACLs

In the default settings after installation, ACLs are deactivated on ext2, ext3, and on reiserfs. They can be activated for supported systems using the "acl" mount option, which should be added at the appropriate place in /etc/fstab (see the SDB article Mounting, Partitioning, and Configuring File Systems SDB:Mounting, Partitioning, and Configuring File Systems. On the jfs and xfs file systems, ACLs are always enabled, so there is no "acl" mount option.

Manipulating ACLs

The basic permissions for the owner, owning group, and for others are also called minimal ACL. In addition to these three entries, an ACL may contain permissions for other users or groups. An ACL that has more than the three basic entries is called an extended ACL.

Files that have an extended ACL are recognized by the additional "+" character that is added to "ls -l" directory listings. The "getfacl" [getfacl(1)] command displays the complete permissions of a file. ACLs are modified with the "setfacl" [setfacl(1)] command. Additionally, "cp -p" copies ACLs between files.

ACLs and Samba

As soon as ACLs are activated, the permissions they define can be manipulated in the Windows NT/2000/XP built-in ACL editor as with permissions on NTFS partitions. No additional software needs to be installed. Samba with ACLs implements all the essential features of a Windows file server. There are only minor differences between how POSIX ACLs and NTFS ACLs are displayed, so people accustomed to Windows ACLs will find themselves in a familiar environment.

ACLs and NFS

The permissions defined in ACLs are also adhered to when accessing the files over NFS. Older NFS clients (NFSv2 and NFSv3 clients before SuSE Linux 8.1) use a permission checking algorithm that is not correct in the presence of ACLs. In certain cases, this may give users of old NFS client software read access to locally cached files to which these users would otherwise not have access. This problem does not exist with SuSE Linux 8.1 clients or when ACLs are not used.

To ensure proper interoperability with old client software, the nfs_permission_mode parameter of the nfsd.o module can be used (e.g., by adding "options nfsd nfs_permission_mode=1" to etc/modules.conf or by loading the nfsd.o module manually with the proper parameter, "insmod nfsd nfs_permission_mode=1"). This parameter causes the server to send permissions to the client that are more restrictive than the real permissions, so the client never generates false positives.

Recent NFSv3 clients query the NFS server when performing access decisions. Older clients (NFSv2 clients and NFSv3 clients before SuSE Linux 8.1) are performing some of the access decisions locally and do not consult the server. In some configurations, the administrator knows that a certain NFS path contains no extended permissions (i.e., no ACLs), so the faster, local access check algorithm is sufficient. In this case, the NFS path can be mounted with the "noacl" mount option, which causes the NFS client to stop consulting the server.

Currently, ACLs cannot be displayed or modified over NFS. This feature will be available in the next version of SuSE Linux. Over NFS, the "getfacl" utility shows only the three minimal ACL entries; "setfacl" fails with "Operation not supported".

Backup and Restore

ACLs currently can only be backed up using the pax archive format (pax is the successor of tar's ustar format and is mostly backward compatible). The tar clone "star" supports the pax archive format with the extensions necessary for ACLs. Other backup utilities, such as GNU tar and dump, will not back up ACLs. If you want to back up ACLs but "star" is not a viable option, produce a plain text dump of all extended ACLs with "getfacl --skip-base -R <dir>". This dump can be restored with "setfacl --restore".

For More Information

We are currently working on more extensive Access Control List documentation. Until more material becomes available, refer to the following sources. One cautionary hint: There are various ACL systems (CISCO, Squid, AFS, NFSv4, etc.) that do not have much to do with POSIX ACLs.

General: http://acl.bestbits.at (not fully up-to-date).
Using ACLs: getfacl(1) and setfacl(1) Manual Pages.
Programming ACLs: acl(5) Manual Page.
Using ACLs under Solaris: Sun World Online (SWOL-08-1996), an article from Forschungszentrums Jülich (German). <keyword>acls,samba,mount,reiserfs,ext2,ext3,xfs,jfs,kernel,filesystem,getfacl,setfacl,chacl</keyword>