ext_attr overlaps

[Robert Watson]

If you're referring to userland, there are some useful things to keep in
mind (these have come up on linux-fsdevel in the last few months).  First,
from the application perspective, directly accessing labels with semantics
(such as ACLs, capabilities, etc) should be done through well defined and
portable APIs, such as POSIX.1e calls.  This is particularly true, I
believe, if the goal is to have a sufficiently abstracted ACL API that it
can support different sets of semantics in the underlying file system
(NFSv4, AFS, Coda, POSIX.1e, ...).  Presumably, in some file systems,
these calls are mapped into general extended attributes (FFS, HPFS, ...),
and others they're stored natively in the file system (AFS, Coda, ...).

This mapping can occur at different levels: the userland ACL API could map
into EAs in the library, the mapping could occur above the VFS mechanism,
or it could occur below VFS in the individual file systems.

In my current FreeBSD implementation, ACL system calls are exposed to
userland (and in some cases wrapped by library calls to handly memory
allocation, such as acl_get_file()).  VFS exposes ACL manipulation and
validation calles from each vnode, and then the individual file systems
store and validate ACLs as they see fit. In the case of FreeBSD FFS,
they're stored in appropriately named extended attributes, and central
POSIX.1e evaluation and validation routines are used for the majority of
the work. 

This is not the only possible implementation, but it's desirable that any
APIs intended to be portable (certainly the library interface, and
possibly the kernel interface). Interfaces within the kernel should be
portable, one hopes, within operating system families (such as *BSD) to
encourage portability of file system implementations.  In any case, if
there is an ACL->EA mapping at some level, then you have to deal with the
fact that you have the same data exposed in both places, and that one is
in a potentially less portable format than the other.  Also, you want
access control protection of both forms to be consistent (or at least for
the EA interface to be more restrictive). 

There's certainly an interest in a number of communities in providing
consistent system call interfaces due to binary emulation techniques that
are widely used (for example, the BSD world benefits a great deal from
Linux emulation); having consistent implementations would also lead to a
higher chance of consistent semantics, and reduce the chances that
application developers take advantage of non-portable implementations. 

Robert N M Watson             FreeBSD Core Team, TrustedBSD Project
robert at fledge.watson.org      NAI Labs, Safeport Network Services


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