Extended attribute interfaces

[Andreas Gruenbacher]

On Thu, 21 Sep 2000, Casey Schaufler wrote:

> 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.

Right, that is a serious deficiency right now.

> 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.

I like that idea very much.

(Modulus keeping all other non-letter first characters reserved for future
extensions, or something like that).

> > 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.

You mean user attributes for device special files. I have completely
missed this distinction so far. User attributes should be treated like
"!attributes" for those files, true.


Thanks,
Andreas.

------------------------------------------------------------------------
 Andreas Gruenbacher, a.gruenbacher at computer.org
 Contact information: http://www.bestbits.at/~ag/

To Unsubscribe: send mail to majordomo at cyrus.watson.org
with "unsubscribe posix1e" in the body of the message