08.06.04

LSHW

Posted in English, Linux at 12:34 am by Rodrigo

This is a very nice tool to list your hardware. Something like this (lshw -html, as root).

Mozilla Tabs

Posted in English, Linux at 12:26 am by Rodrigo

This is a little script I wrote to ease the interaction between mozilla and the rss-grab gdesklet.

The script checks if there’s an instance of mozilla running. If there is, it opens the url given as argument in a tab inside the running mozilla instance. If there isn’t, it creates a new instance of the browser.

Run this script (instead of mozilla) when there’s a click in one of the gdesklet url’s, and bingo! No more multiple mozilla instances!

Reference: http://www.mozilla.org/unix/remote.html.

07.28.04

ACL’s in Linux

Posted in English, Linux at 12:15 am by Rodrigo

Yesterday, at work, we needed some security policies to access files in a Linux server. Perfect time to deploy ACL support.. but first, I had to investigate how to do this.

First: Kernel support for ACLs

Right now (kernel 2.6.7), Linux has support for ACLs in all the major filesystems: ext2, ext3, reiserfs, jfs and my favorite: xfs (I will discuss this favoritism in another article). The support has to be enabled in the kernel, with the respective options:

  • CONFIG_{EXT2,EXT3,REISERFS}_FS_POSIX_ACL (which depend on CONFIG_{EXT2,EXT3,REISERFS}_FS_XATTR: filesystem extended attributes) for ext2, ext3 and reiserfs respectively,
  • CONFIG_JFS_POSIX_ACL for JFS, and
  • CONFIG_XFS_POSIX_ACL for XFS.

All of them, except XFS, use the same POSIX ACL kernel infrastructure for common system calls (option CONFIG_FS_POSIX_ACL). XFS uses its own, but it’s totally compatible (after all, all of them are POSIX ACLs), so the applications in user space see the same thing.

Second: The filesystem

The filesystems (at least the ones I tested: reiserfs and xfs) are not created with ACL support: this is added in a per-file basis only when one explicitly sets the ACL. The filesystems just have to be mounted with the “acl” option:

% mount -o acl /dev/foo /bar

As always, XFS does its own: if kernel support for ACLs in XFS is enabled, one doesn’t need to use the “acl” mount option, because it’s implicitly used (actually, ACLs can’t be disabled if the kernel support is enabled.. not that it matters too much, because the performance and disk cost is negligible).

Set the “acl” option in /etc/fstab for the filesystems you want ACL support enabled and the super-user configuration is over.

Third: Setting and Getting ACLs

Now we need application support. In Debian, SuSE and Fedora, the package is called ‘acl’, and it has the two commands we need to set and get ACLs: setfacl and getfacl (it has another command: chacl, but that is for IRIX compatibility only).

All files in an ACL-enabled filesystem have the default basic ACL, which corresponds exactly to the permissions given to the file in the non-ACL-enabled filesystem. This permissions can be read with getfacl, like this:

% getfacl acl.txt
# file: acl.txt
# owner: rodrigo
# group: staff
user::rw-
group::r--
other::r--

You can see the permissions are the same that can be set with chmod: read, write and execute for user, group and other. The file name, owner and group can also be seen in the output.

Now the interesting part: files can have “extended ACLs”, which are an extension of the classical Unix permission model. For example, if I don’t want anyone to mess with my file, I usually use chmod 600 acl.txt, like this:

% chmod 600 acl.txt
% getfacl acl.txt
# file: acl.txt
# owner: rodrigo
# group: staff
user::rw-
group::---
other::---

Now, I want to grant the permission to read and write my file to another user, “chacal”.. but we’re not in the same group! With the classical Unix model, I would have to create another group exclusively for me and chacal, add both users to the group, change the group ownership of the file to the new group and set the permissions of the file to 0640. With ACLs, I use:

% setfacl -m u:chacal:rw acl.txt
% getfacl acl.txt
# file: acl.txt
# owner: rodrigo
# group: staff
user::rw-
user:chacal:rw-
group::---
mask::rw-
other::---

You can see that there are two new fields in the acl: another user and a mask. We see that this user, chacal, can read and write the file, like the owner. But the mask purpose is not so clear. It represents the maximum set of permissions all fields can have, except user:: and other::. The effective permissions given to chacal are what appears in user:chacal (rw-) and’ed with the mask (rw-). If we limit the mask:

% setfacl -m m::r acl.txt
% getfacl acl.txt
# file: acl.txt
# owner: rodrigo
# group: staff
user::rw-
user:chacal:rw-                 #effective:r--
group::---
mask::r--
other::---

We see that though the user permissions still are ‘rw’, the mask only permits read, so that’s what chacal gets.

If we want to remove chacal permissions, we set his access to zero (setfacl -m u:chacal:- acl.txt) or we can remove him completely from the list (setfacl -x u:chacal acl.txt).

Regular files only have one kind of ACL, called the ‘access ACL’. Directories have two ACLs: the access ACL and the default ACL, which is used to set the initial ACL of new files created inside the directory (only for files created after the default ACL has been set). This default ACL is manipulated in the same way access ACLs are; we just have to put the ‘-d’ flag in the setfacl command.

% mkdir hello
% chmod 755 hello
% setfacl -d -m g::- hello
% setfacl -d -m o::- hello
% setfacl -d -m u:chacal:rx hello
% getfacl hello
# file: hello
# owner: rodrigo
# group: staff
user::rwx
group::r-x
other::r-x
default:user::rwx
default:user:chacal:r-x
default:group::---
default:mask::r-x
default:other::---

% cd hello
% touch bye
% getfacl bye
# file: bye
# owner: rodrigo
# group: staff
user::rw-
user:chacal:r-x                 #effective:r--
group::---
mask::r--
other::---

As you can see, the file has inherited its access ACL from the default ACL of its parent directory. The same happens with directories, though they also inherit the default ACL from their parent.

Fourth: Application support for ACLs

What happens with ACL support in existing applications? As far as I know, the usual kernel system calls (like open(2) or creat(2)) know about ACLs, and inherit them from the parent directory (if this directory has a default ACL).

Common applications like ls, cp, mv know about ACLs: mv moves ACLs even between filesystems of different type (xfs to reiserfs, etc.). cp with the -p (preserve) flag does the same. ls needs some explanation: when a file has a basic ACL, the output of ls is the same:

% ls -l bye
-rw-r--r--  1 rodrigo staff 0 Jul 28 16:23 bye

This means that the file ‘bye’ has read and write access to the owner (me), and read access for the members of the group ‘staff’ and for everyone else. If a file has an extended ACL, the output is:

% ls -l acl.txt
-rw-r-----+ 1 rodrigo staff 0 Jul 28 12:40 acl.txt
% getfacl acl.txt
# file: acl.txt
# owner: rodrigo
# group: staff
user::rw-
user:chacal:rw-                 #effective:r--
group::---
mask::r--
other::---

As you can see, in this case the meaning of the fields is different. First, the presence of an extended ACL is displayed using a ‘+’ character after the permission fields. The permission fields are read in the same way as the basic ACL, except the middle one (the group permission), which is replaced by the mask of the ACL.

Other applications may or may not have support. Of the ones I tested, gzip, bzip2 and tar don’t have support. Files compressed or tar’ed using these tools lose their ACLs. For tar there is an alternative, star, which does ACLs and a couple of other things (complete unicode support and unlimited filename length, among others).

For python lovers (like me) there is a library which can be used to manipulate ACLs from inside an application: pylibacl (debian users: python-pylibacl).

This has been the exciting world of POSIX Access Control Lists.. See you!

« Previous Page « Previous Page Next entries »