patch draft for extended attributes on linux

Carson Gaspar carson at taltos.org
Fri Jun 27 01:43:40 EST 2003



--On Thursday, June 26, 2003 1:16 AM -0700 jw schultz <jw at pegasys.ws> wrote:
>> Impossible with simple user/group permissions.
>
> Not impossible.  I've done that sort of thing many times.
>
> -rwxr-x---    1 charlie   cdab         3658 Jan 20 17:35 .
> -rw-rw-r--    1 charlie   david        3658 Jan 20 17:35 the_file
> Or so you don't need root to "chgrp david the_file"
> -rw-rw-r--    1 charlie   charliedave  3658 Jan 20 17:35 the_file

And how does the group charliedave get created? And what happens when you 
need to add Ed to the list?

I cede the point of it being possible. That's what comes from writing 
technical e-mail late at night ;-). It's still horrific and unmanageable.

> You will find that most definitions of ACLs--including
> POSIX--only allow you to grant access, not revoke it.

Then those ACLs are just plain broken. Solaris ACLs definitely allow you to 
revoke privileges (by granting mode 0000 to a user/group).

> My point is that i'm not going to anguish over broken
> regimens that use xattrs to tighten the security.

Broken? Hardly. Default deny is a good philosophy in general, but is not 
practical in many cases. Simple example from the real world - you have a 
set of untrusted users (say, vendor support accounts) and you want to lock 
down certain sensitive information on the box so they can't see it. You 
either have to maintain a good users list, with every account in the firm 
in it, and keep it up to date, or you can just deny access to the static, 
small, bad users list.

Another counter example is the immutable flag. It definitely revokes 
permissions.

> ACLs and capabilities should be used to grant, not revoke.
> That way if something happens that looses or disables xattrs
> your system is not compromised.  Further by applying the
> xattrs last you ensure that the file is intact with correct
> ownership before enabling anything.

Sadly, the way ACLs and simple permissions interact is _very_ OS specific. 
The correct order to apply permissions will vary by platform. Under 
Solaris, acl()/facl() set the default user/group/other perms as part of the 
ACL, so there's no ordering drama. If this isn't the case in other 
implementations, the right thing is probably:

- Create temp file mode 000 (or 200 if necessary)
- Change perms to 000 (if necessary)
- Change owner / group
- Change ACL / xattr
- Change simple perms
- Rename file

If the ACL grants access, no problem. If the ACL revokes access, no problem.

Of course, if there is an xattr that will forbid renaming the file, or 
forbid changing the file's permissions, you're in trouble. But then you're 
screwed anyway, because you have to rename the file into place before 
setting the xattr, leaving a window with the file in existence with 
incorrect permissions.

-- 
Carson




More information about the rsync mailing list