Extended attribute interfaces

[Robert Watson]

On Thu, 21 Sep 2000, Casey Schaufler wrote:

> Actually, it occurs to me that if we put a prefix on "other"
> attributes as well (how about "?attributes") we never have to
> worry about new prefixes. We could either require that users
> specify the '?' or we have the syscall prepend it to any
> attribute name without a recognized prefix. I'm inclined
> toward to former, with the libraries doing the job of the
> latter.

I find the the distinctions you've suggested make sense:

Kernel EAs: Extended attributes intended for consumption and use by the
kernel, to back file system services such as ACLs, et al, to.

System EAs: Extended attributes that may be consumed by userland or
kernel, but require privilege to do so from userland (CAP_EXT_ATTR or the
like).

Application EAs: Extended attributes intended for consumption by userland
applications, subject to the mandatory and discretionary protection
provided to the normal file data.

I still find myself uncomfortable with the prefixing of funky characters
to the front of the attribute name hower.  At some point, I'd just prefer
to have different API calls, in that case:

  extattr_system_get_file()
  extattr_application_get_file()

  extattr_get(EA_SYSTEM, )
  extattr_get(EA_APPLICATION, )

It's immediately obvious to the programmer what these mean, whereas the
distinction between '$cap', '.cap' and '?cap' does not immediate present
itself :-).  The advantage to the londer name selection is that it is
clear what it means.  I'd be happy to have the POSIX.1e-like API resemble
either of the two options above, with the syscall API working however the
implementation feels necessary.  As described before, namespace mapping
(any of name->index, multiple namespaces to single namespace, single
namespace to multiple namespaces) could happen in the library, kernel,
file system -- wherever.

One idea that I continue to find uncomfortable is that the portable
interface to POSIX.1e security labels would involve using EA interfaces
-- i.e., I much prefer cap_get_file(), acl_get_file(), mac_get_file()
because they work regardless of where the labels are actually stored
(inode, EA, et al).  This suggests that portable backup tools (tar, et al)
should use POSIX.1e interfaces for system/kernel attributes, and that
local tools such as dump could access the EAs directly if they choose.

> > You mean user attributes for device special files.
> 
> Sigh. No, I mean the Irix equivalent of devfs.

In 5.0-CURRENT of FreeBSD, we support attaching EAs to special devices and
fifos in the file system, but our devfs does not currently handle these.
This is presumably something I'll have to fix, but I'm not sure what the
best direction for persistence is.

  Robert N M Watson 

robert at fledge.watson.org              http://www.watson.org/~robert/
PGP key fingerprint: AF B5 5F FF A6 4A 79 37  ED 5F 55 E9 58 04 6A B1
TIS Labs at Network Associates, Safeport Network Services

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