Extended attribute interfaces

[Casey Schaufler]

Andreas Gruenbacher wrote:

> In my design there simply is no way to set a system attribute that is not
> known by the kernel at all, not for anybody. So the only choices the
> backup system would have is to either implement a minimal handler for such
> an attribute (including all policy issues) or use a user attribute (which
> would then be subject to the same restrictions as the file contents, like
> in Irix).

I was about to complain that a scheme which doesn't support
trusted application sub-systems is of limited value when it
occurred to me that there's an obvious solution.

Make "$attributes" be kernel only, for ACLs and such.

Make "+attributes" be system protected, requiring CAP_EXT_ATTR
to access.

Make "!attributes" be accessable as are mode bits, that is,
publicly readable, owner writeable.

Make all other attributes accessable as is file data.

> What's the mechanism Irix uses exactly? I seem to remember that root can
> set root attributes, and other users can set user attributes, but in a
> Posix.1e system such a distinction seems wrong to me.

CAP_FOWNER controls access to root extended attributes on Irix.
User attributes are controlled as file data on XFS, but as
mode bits on /dev.

-- 

Casey Schaufler				Manager, Trust Technology, SGI
casey at sgi.com				voice: 650.933.1634
casey_p at pager.sgi.com			Pager: 888.220.0607
To Unsubscribe: send mail to majordomo at cyrus.watson.org
with "unsubscribe posix1e" in the body of the message