Trustees Linux [LWN.net]

Linux currently offers a wealth of projects which are working to extend the classic Unix permissions mechanism with more flexible schemes. One recent entry is an LSM port of Trustees Linux, which has been done by Andrew Ruder. Trustees Linux starts with the idea that access control lists are overly complicated and inefficient; achieving the desired goals can require hanging ACLs on thousands of files, and keeping all of those ACLs in sync can be a challenge.

The Trustees approach, instead, is to create a separate, central database which contains filesystem permissions. This database can assign a "trustee" to a directory; this trustee provides access permissions which apply to the directory and, by default, everything below that directory. A single rule can, thus, cover a large part of the filesystem hierarchy.

The trustee rules cover the usual sorts of permissions; who can search for, read, and write files in a given subtree. The format is somewhat terse; one of the rules provided in the examples is:

    [/dev/hda1]/var/log:zavadsky:REB

This rule enables user "zavadsky" to wander around in (and under) /var/log and read files there.

Mr. Ruder's port is centered around the Linux security module inode_permission() hook; that code examines the trustees which apply to a given inode and decides whether the requested access is to be allowed or not.

It's all pretty straightforward, but there is an interesting twist to how Trustees works with file permissions: the module gives the CAP_DAC_OVERRIDE capability to every process, allowing them to override the existing Unix file permissions. The Trustees module will, in turn, apply those permissions itself much of the time, but it is possible to write rules which override them. In this sense, Trustees functions as an authoritative module, which is not how LSM modules are supposed to work. If Trustees Linux is ever proposed for merging into the mainline, that little feature could come back to haunt it.

(Log in to post comments)

Trustees Linux

Posted Nov 19, 2004 23:11 UTC (Fri) by smeg4brains (guest, #207) [Link]

We use trustees on our current file server and have really liked it. It's nice that there's one central location that we can use to audit the permissions of our entire file server. They're quick, they use virtually no disk space aside from the text file that stores the permissions (the same can't be said for acl's and their extended attributes), they're simple to install and use, and they work no matter what filesystem you're using.

The downsides: The documentation that has historically existed for them has been not so hot, and I've never had much luck trying to get answers from the original developer (even when my company was hoping to pay him to extend part of his software). It's really great to see someone else working on them. On our old fileserver, the "clear" attribute either never worked properly or reliably, or it was never intended to do what we thought it was. It was never possible for us to tell, since the documentation never really made it clear at all.

I think the CAP_DAC_OVERRIDE hack is just fine. I'm sure there's no other way to add permission capabilities. The only other option for a setup like ours would be to chmod -R 777 *, and then use trustees to remove permissions again, but then we always end up running into problems where some files got put there later, but without 777 and then someone can't read it. It's nice actually to have the permissions be dependant on a files location in the tree.

One last downside. At least on our version of trustees (and I'm guessing all versions), if you try to grant full rights to a tree, but then have one subdirectory that has tighter permissions, then you end up with no *real* security at all. A person can go up to a higher directory, rename the directory to something else, and the trustee permissions no longer apply. It would be nice if there were some check on directory renaming that could catch this sort of thing and prevent the rename. Maybe a bit that gets flipped on the dentry that marks it as dirty meaning that there is a trustee setting somewhere below, and the directory rename could be denied.

Trustees Linux

Posted Nov 24, 2004 2:51 UTC (Wed) by aeruder (guest, #22597) [Link]

I had not thought of this situation. I did do a some work in this one
preventing a similar thing with making hard links. I will see what can be
done about this situation as well.

Trustees Linux

Posted Nov 18, 2004 10:53 UTC (Thu) by jamesh (guest, #1159) [Link]

ACLs don't have to be complicated. The Windows ACL implementation has a nice feature of being able to inherit the parent's ACL as a base for the file's ACL.

If every file in the system has this bit set in their ACL, the permissions of the root directory will apply to every file on the system. If you apply an ACL to someone's home directory, those permissions will apply to every file inside it, etc.

This covers much of the ease of use problems with ACLs, since you don't usually need to apply ACLs to many files/directories.

Trustees Linux

Posted Nov 18, 2004 14:25 UTC (Thu) by duck (guest, #4444) [Link]

Hi,

As far as I know the default ACLs on a Linux directory (if enabled ans
supported by the file system!) work very much the same way...

Cheers

Peter

Trustees Linux

Posted Nov 18, 2004 15:54 UTC (Thu) by bfields (subscriber, #19510) [Link]

> As far as I know the default ACLs on a Linux directory (if enabled ans
> supported by the file system!) work very much the same way...

One crucial difference: default ACLs on a directory are copied onto newly created objects in the directory, but don't affect preexisting objects. In Windows, my understanding is that children just reference the inheritable ACLs on their parents, so a change to an inheritable ACL on a parent (or any ancestor) immediately affects the child.

Trustees Linux

Posted Sep 12, 2007 22:05 UTC (Wed) by bfields (subscriber, #19510) [Link]

Hah. I just happened across this 3-year-old comment and noticed that it's totally wrong. At least, from what Windows documentation I've read since then, Windows works just like Linux in this case, except its acl model makes it easier to propagate changes to inheritable acls recursively.