/ Markus Amersdorfer:home / university / about:me /
\ Say NO to Software-Patents! \


EXT2/EXT3 and POSIX ACLs on Debian Woody

Table of Contents

Introduction

Andreas Grünbacher is the author of the Extended Attributes (EA) and Access Control Lists (ACL) code for EXT2/EXT3 filesystems. The homepage is to be found at acl.bestbits.at. As far as I can tell, meanwhile even XFS' and JFS' implementations of ACLs are based on Grünbacher's code. (Please correct me if I'm wrong.)
I'll describe how to get this stuff working on a Debian Woody based machine while trying to stick to DEB-packages as much as possible.

Before you proceed any further: Download and read the ACL section from SUSE's Admin-Guide, linked to from the ACL about page at bestbits.at. It really enhanced my understanding of what is to be used in which way.

Patching the Kernel

2.4.20

Patch a fresh linux-2.4.20 from kernel.org using ea+acl-0.8.56 (http://acl.bestbits.at/current/diff/ea+acl-2.4.20-0.8.56.diff.gz):

  cd /usr/src/
  patch -p0 < ea+acl-2.4.20-0.8.56.diff

Recompile the kernel, using the following options in section "File system":

  [*] POSIX Access Control Lists  
        [this option might not work in "make xconfig",
          use "make menuconfig" if selection isn't possible]
  [...]
  <*> Ext3 journalling file system support
  [*]   Ext3 extended attributes
  [*]     Ext3 extended attribute block sharing
  [*]     Ext3 extended user attributes
  [*]     Ext3 trusted extended attributes
  [*]     Ext3 POSIX Access Control Lists
  [ ]   JBD (ext3) debugging support
  [...]
  <*> Second extended fs support
  [*]   Ext2 extended attributes
  [*]     Ext2 extended attribute block sharing
  [*]     Ext2 extended user attributes
  [*]     Ext2 trusted extended attributes
  [*]     Ext2 POSIX Access Control Lists
  [...]

2.4.21

Patch a fresh linux-2.4.21 from kernel.org using ea+acl+nfsacl-2.4.21-0.8.60.diff (http://acl.bestbits.at/current/diff/ea+acl+nfsacl-2.4.21-0.8.60.diff.gz):

  cd /usr/src/
  patch -p0 < ea+acl+nfsacl-2.4.21-0.8.60.diff

Recompile the kernel, using the following options in section "File system":

File systems --->
  <*> Ext3 journalling file system support
  [*]   Ext3 extended attributes
  [*]     Ext3 extended attribute block sharing
  [*]     Ext3 extended user attributes
  [*]     Ext3 trusted extended attributes
  [*]     Ext3 POSIX Access Control Lists
  [ ]   JBD (ext3) debugging support
  [...]
  <*> Second extended fs support
  [*]   Ext2 extended attributes
  [*]     Ext2 extended attribute block sharing
  [*]     Ext2 extended user attributes
  [*]     Ext2 trusted extended attributes
  [*]     Ext2 POSIX Access Control Lists

If you also want NFS to support ACLs:

File systems --->
 Network File Systems  --->
  <*> NFS file system support
  [*]   Provide NFSv3 client support
  [*]     Solaris ACL RPCs
  <*> NFS server support
  [*]   Provide NFSv3 server support
  [*]     Solaris ACL RPCs
Library routines  --->
  <*> Quick Sort

I'm sorry, I haven't checked out the NFS options yet. Update as soon as possible.

2.4.24

The patch for 2.4.24 is available and fixes a possible file system corruption bug.

/etc/fstab

Add option "acl" (and/or "user_xattr") to /etc/fstab:

  /dev/md1  /  ext3  defaults,acl  0 1

Install the kernel and reboot.

Setting ACLs

In order to set ACLs on a file/directory, simply install the package "acl" using apt-get. This provides the programs "setfacl" and "getfacl":

Set ACL for "extrauser":
  setfacl -m u:extrauser:rw acl-file.txt

Set ACL for "extragroup", recursive:
  setfacl -Rm g:extragroup:rwx directory/

Set Default ACL, recursive:
  setfacl -Rdm g:extragroup:rwx directory/

Oh, and don't forget the man-pages! :)

automake1.6

In order to get the Debian-package fileutils_4.1.8-0.1_i386.deb compiled later on, first install automake1.6 on a Woody-machine.
As automake1.6 only exists for Debian Sarge and later, use "apt-get source automake1.6" on Sarge machine to get the source, and use "dpkg-buildpackage" afterwards on a Woody machine to get a working automake1.6 package for Woody.

Here's how to do that:
mkdir ~/automake1.6; cd ~/automake1.6; dpkg-buildpackage. The output told me there were "Unmet build dependencies: debhelper (>> 4.0), autotools-dev (>= 20010511.2), texinfo", so I installed these and according extra-packages: apt-get install debhelper autotools-dev texinfo. A dpkg-buildpackage should work now.
Trying to install the resulting DEB-package using dpkg -i automake1.6_1.6.3-5_all.deb now raised another problem: autoconf is needed. I installed it, with Woody's selection removing automake1.6 again as automake (which it needs due to autoconf) conflicted with my automake1.6. After having autoconf installed, I removed automake manually (dpkg -P automake) and installed automake1.6 (dpkg -i automake1.6_1.6.3-5_all.deb).

Here is my .deb-file: automake1.6_1.6.3-5_all.deb.
(Mind: it's some time since I've built this stuff and I didn't double check while writing this. If this is not the correct package, please mail me...)

Patching "fileutils"

Update -- 2004-02-15:
Debian Sarge's "coreutils" package, which includes "fileutils", features ACL/EA support as of 5.0.90-3. (Thanks to "undefined" for the exact link.)

Patching the package "fileutils" is necessary in order to get a visual indication of ACLs set for files/directories when listing a directory using "ls -l" (the visual indication is a "+" after the access-rights-block) and - even more important - to have ACLs being copied using the command "cp -p". Using the standard-fileutils, the ACLs will be lost after copying the file(s).

My work here is based on stuff I found on the homepage http://pint.pmhahn.de/pmhahn/debian/woody/f/fileutils/. Many thanks to its creator Philipp Matthias Hahn!

Before continuing: If you want to compile the package yourself, you'll need automake1.6.

I downloaded the files fileutils_4.1.8.orig.tar.gz, fileutils_4.1.8-0.1.diff.gz and fileutils_4.1.8-0.1_i386.changes.

Execute:
  # tar xzf fileutils_4.1.8.orig.tar.gz
  # mv fileutils-4.1.8.orig/ fileutils-4.1.8
  # gunzip fileutils_4.1.8-0.1.diff.gz
  # patch -p0 < fileutils_4.1.8-0.1.diff
  # cd fileutils-4.1.8/
  # chmod +x debian/rules

Add to lib/acl.c:
  #ifndef NULL
          #define NULL    0
  #endif

Edit aclocal.m4:
  Change "1.6" to "1.6.3" three times.

Editing aclocal.m4 is necessary in order to have "make" succeed and not exit with an error telling you that the aclocal-version used is 1.6.3 and not the 1.6 which was used previously to build the file aclocal.m4. The "make"-output tells you to run "aclocal" (followed by "make" again), but running "aclocal" seems to break a lot of things ... so just pretend aclocal.m4 was built with the version you have installed (as 1.6.3 is Debian Woody's version).

A "dpkg-buildpackage" might result in "Unmet build dependencies" again, so just install the needed packages. (In my case, this was apt-get install gettext groff. Two of the most important packages you will need are "acl-dev" and "attr-dev".)
Run "dpkg-buildpackage" again. If it returns with value "0" (check this by running "echo $?" directly after the program returns), everything should have worked fine and you should be able to install the .deb-file.

So, the only thing left here is to install the package: dpkg -i fileutils_4.1.8-0.1_i386.deb.

Of course, you should test it:

  # ls --version
  ls (fileutils) 4.1.8acl
  Written by Richard Stallman and David MacKenzie.
  [...]

  /tmp# ls -l
  total 8
  -rw-rw-r--+   1 max      max            34 Apr  7 14:35 acl-test.txt

  /tmp# cp -p acl-test.txt acl-test_COPY.txt

  /tmp# ls -l
  total 16
  -rw-rw-r--+   1 max      max            34 Apr  7 14:35 acl-test.txt
  -rw-rw-r--+   1 max      max            34 Apr  7 14:35 acl-test_COPY.txt

You can see the "+", indicating that both files acl-test.txt and its copy have ACLs set.

Here's my .deb-package: fileutils_4.1.8-0.1_i386.deb.
(Mind: it's some time since I've built this stuff and I didn't double check while writing this. If this is not the correct package, please mail me...)

Upgrading e2fsprogs

Woody uses version 1.27.
Since version 1.28, the e2fsprogs support ACLs by default, so let's upgrade to a newer version than Woody's: Sarge's 1.32.

On the Sarge-machine, run "apt-get source e2fsprogs" and copy the stuff over to a Debian Woody machine.
On the Woody-machine, run "dpkg-buildpackage" again. (Again, you might have to resolve "Unmet build dependencies", in my case this was "texi2html".)

dpkg-buildpackage creates the following files:
  -rw-r--r--    1 root     root        39160 Apr 14 14:40 comerr-dev_2.0-1.32-2_i386.deb
  -rw-r--r--    1 root     root       239358 Apr 14 14:40 e2fsck-static_1.32-2_i386.deb
  -rw-r--r--    1 root     root       113242 Apr 14 14:40 e2fslibs-dev_1.32-2_i386.deb
  -rw-r--r--    1 root     root       175944 Apr 14 14:40 e2fsprogs-bf_1.32-2_i386.deb
  -rw-r--r--    1 root     root       118146 Apr 14 14:40 e2fsprogs-udeb_1.32-2_i386.udeb
  -rw-r--r--    1 root     root         2102 Apr 14 14:40 e2fsprogs_1.32-2_i386.changes
  -rw-r--r--    1 root     root       365102 Apr 14 14:40 e2fsprogs_1.32-2_i386.deb
  -rw-r--r--    1 root     root        13862 Apr 14 14:40 ss-dev_2.0-1.32-2_i386.deb
  -rw-r--r--    1 root     root        13408 Apr 14 14:40 uuid-dev_1.2-1.32-2_i386.deb

As I had only "e2fsprogs" installed already, this was the only package I upgraded using "dpkg -i e2fsprogs_1.32-2_i386.deb".
Here's my .deb-package: e2fsprogs_1.32-2_i386.deb.
(Mind: it's some time since I've built this stuff and I didn't double check while writing this. If this is not the correct package, please mail me...)

Installing star

"star" is a program similar to "tar", but which takes care of ACLs too... just run "apt-get install star".

Backups

There is no direct way of correctly backing up your data with your ACLs as most backup software does not take care of ACLs.
Nevertheless, there's a workaround: Install the Debian package "acl" (if not already done). It provides the programs getfacl and setfacl. These can be used to get the current ACLs respectively change them or set new ones.
getfacl *
setfacl -m u:ursula:rw file1
(Here is the man-page for setfacl.)

Backing up:
Choose whether you want to back up all your system's ACLs to one file, or whether you want several split lists. (I chose to back up ACLs separately for each filesystem, as it should be a bit easier to recover from a fatal system crash). For each directory tree you want to back up, issue a command like the following:
root@t4u:/home # getfacl -R --skip-base . > backup.acl
The `--skip-base' option excludes all files that only have the three base ACL entries (user, group and other). You do not need to back these up separately as the base ACL entries correspond to the file mode permission bits, which I assume your backup utility handles already. The `-R' option tells getfacl to recurse into subdirectories.

Restoring:
The data written to the backup file is the same output you are used to from using getfacl all the time. The setfacl utility is able to parse this output, and restore all the all permissions (including the owner and owning group, if you have privilege to change these). For restoring the backup from above, type:
root@t4u:/home # setfacl --restore=backup.acl

Personal add-on:
The package "acl" also provides "chacl" which is an SGI program in order to change ACLs.
"chacl -l" and "chacl -r" are Linux-only options and might also do something similar to the backup process described above. (http://acl.bestbits.at/man/man.shtml linking to http://acl.bestbits.at/cgi-man/chacl.1.)

NFS

In order to solve problems with NFS using ACLs, you need to apply the nfsacl-patch available at acl.bestbits.org. It is for the kernel NFS daemon only.
More info can be found here.

Drawback: Different Behaviour of chmod g[+-][rwx]

Bear in mind that, with all ACL-patches and packages in place, the functionality of chmod g[+-][rwx] changes: For files that have no ACLs set (but use the normal user/group/others -rights only), running something like chmod g+w upload-dir/ changes the access rights to allow the group to write to this directory. This is the normal behaviour.
As soon as a file/directory has any ACL(s) set, the behaviour of chmod g[+-][rwx] changes: The command does not change the access-rights of the actual group the file belongs to, but it rather changes the "ACL mask" entry.

While it is possible this way to non-intrusively revoke write-access for all parties at once (except for the user itself) and re-grant it later on, I definitely would have liked a specific command or option to setfacl better in this case: The (IMHO) problem with the implemented behaviour is that it is not possible to widen access rights with something like chmod g+w beyond the state the file/directory had set when the first ACL was added to it. This means that for example directories, that are usually created "750" and for example have Apache's "www-data" set for the group, can not be changed by the user via FTP to allow Apache to write into this directory. While this is often used for file-upload or similar, and with the situation that the users do not have shell-access (but FTP/Web only), it would be necessary for the user to tell the network admins about their need and for the network admins to manually run the corresponding setfacl command to grant Apache write-access. :(
(While the FTP client invokes sth. like chmod g+w upload-dir/, this only changes the ACL mask, but it does not change the group's initial "r-x" in any way, resulting in no change of the access-rights for the group "www-data", effectively. Furthermore, it would not make sense to create the directory with "770" in the first place, set the mask to "750" and add recursive ACLs to allow your network's staff-/admin-group full access, as the latter would not have write-access either because of the "750" mask bits...)

See this thread on the ACL mailing-list for more information.

If you know of a solution to this problem, pleeeze let me know!

Miscellaneous

back to index

Valid HTML 4.01! Valid CSS! Created with Vim [Blue Ribbon Campaign icon]
© Markus Amersdorfer (markus<dott>amersdorfer<att>subnet<dott>at)
last modified: 2010-02-23 15:51:49
842 hits