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.