Extended attribute interfaces

[Robert Watson]

On Tue, 20 Jun 2000, Andreas Gruenbacher wrote:

> All,
> 
> here are some more thoughts on extended attributes in response
> to Robert Watson's message from 18 Jun 2000 12:50:25 -0400 (EDT).
> 
> Please comment...
> 
> I can imagine the following operations on extended attributes:
> get, set (implicit create), remove, enumerate.

Looks good.  In my VOP_ interface in the kernel, remove is actually a set
with a NULL pointer for the uio source.  However, in my syscall interface,
I currently explicitely expose a remove call.  Either way sounds fine to
me; reducing the number of calls might make sense, especially if we are
reducing enumerate to get. 

> There are other more complex operations for atomically
> updating a number of extended attributes, passing flags like
> O_CREAT and O_EXCL when modifying extended attributes, etc. I
> think we don't really need this level of complexity. Many such
> ideas can be found in Tru64 manual pages, see
> <http://www.unix.digital.com/faqs/publications/pub_page/doc_list.html>.
> 
> I think we agree about get, set and remove. I think we also
> agree that extended attributes are not like files. Accessing
> doesn't require to open()/.../close() a stream. Instead,
> attribute values are copied in and out of a buffer atomically.
> This simplifies the interface, and also makes it faster.

Sounds good.

> I have implemented and favor the latter approach (copy the list
> of EA names into a buffer). My expectations are that there will
> be not so many extended attributes for a single file. I assume
> a maximum upper limit (of, say, 50 EAs) is no problem at all.
> Assuming that there will only be a low number of extended
> attributes, fetching a list of attribute names into a buffer is
> faster than opening an enumeration, fetching entries,
> and closing the enumeration. No state must be kept in the kernel.
> 
> The disadvantage of this interface is that it has a scalability
> problem with large numbers of attributes.

Performing a get on a NULL extattr name, a method we've discussed in
email, sounds good to me.  That said, I agree that minimizing the number
of syscalls is useful.  Elsewhere, you have suggested a two-phase get
process: first determine space required (possibly by using a moderate size
buffer, then getting back the real size and trying one the right size).
This would also work for retrieving attribute names in the same way.

Open questions in my mind include the storage format -- arrays of dirents
of fixed length, making parsing easier?

> There might be another problem with enumerating attributes.
> In my current implementation, everyone with search access to
> a file may obtail the list of attribute names defined for that
> file. (permission to read the attribute value may still be
> denied.)
> 
> This seems fine for user attributes. I'm not sure whether the
> knowledge that a file is associated with a certain system
> attribute is sensitive information.
> 
> It might become necessary to hide system attributes from
> non-privileged processes (e.g., expose all attributes to
> processes capable of CAP_DAC_READ_SEARCH, but hide system
> attributes from all processes not capable of
> CAP_DAC_READ_SEARCH, or something similar).

For the purposes of backup and so on, it makes sense to be a bit cautious
about exposing attribute lists.  One concern that comes to my mind is
backup utilities that understand both extended attributes and ACLs.
Should they back up one?  If so, which?  If not, then both?  The attribute
name itself might be implementation-dependent, and duplicate retrieval of
the same data could result in (at best) inefficient storage.  At worst,
you can imagine tarring on FreeBSD and untarring on Linux, and getting
some bizarre results. :-)

> We (robert and I) have discussed which sybol to use. Currently,
> I'm using ENOATTR, which is an alias to EDOM. This of course is
> a hack. I would favor having a real ENOATTR symbol in glibc.
> Using any of the existing error codes is not very appropriate;
> strerror() would give a wrong message.

I agree.  I'm currently using ENOENT, but ENOATTR sounds great to me.
Unless there is substantial objection in some field or another, I'll go
ahead and introduce ENOATTR on FreeBSD prior to the 4.1 release, although
the actual current implementation won't be available until 5.0.

> ATTRIBUTE NAMESPACES
> 
> Robert has already mentioned there are two attribute namespaces
> on Irix (user and root). In my Linux implementation, there is a
> user and a system namespace. However, im my implementation the
> only difference between a user EA and a system EA is the
> attribute name: system attributes start with a '$' character,
> while user attribtes start with an English-alphabet character.
> 
> At the filesystem level, it makes no sense to make a difference
> between user and system attributes. The difference only is how
> the kernel uses extended attributes, not how they are stored.
> So encoding the attribute namespace in the attribute
> name also simplifies the interface between the kernel and
> file systems.

I agree.  However, please see my comments above on backups and
dual-interfaces to the same data.  This is part of what motivated my
original suggestion that only user extended attributes be backed up -- if
system attributes are not backed up / enumerated, the dual namespace isn't
a problem.

> If I understood correctly, Robert suggests to manipulate user
> attributes using one set of system calls, and to manipulate
> each different system attribute using a separate mechanism.

Well, originally I suggested one set of system calls, before agreeing that
really we needed two namespaces.  I like the ``$'' escaping mechanism, but
an IRIX-like flag indicating the namespace would also be fine.

> One disadvantage of this `unified' interface is that the
> kernel needs to look up a handler in the system calls.
> The overhead involved is minimal, though.

I don't see this as a serious impact, but what does worry me is the
divergent behavior based on privileges.  Typically, I favor an interface
that returns success+data or failure, not success+data or
failure+differentdata.  This simplifies things from the perspective of an
access controlling tool, and management of data flow.  In this manner, a
flagged interface would be cleaner.

> ATTRIBUTE PERMISSIONS
> 
> In Irix, user attributes are subject to the same permissions as
> the file/directory they are associated with. As this seemed to
> make sense for me, I've implemented it that way for Linux, too.
> 
> For system attributes, it depends on the specific attribute
> which permissions are required for retrieving and setting. For
> example, setting ACLs is allowed for the owner and for processes
> capable of CAP_FOWNER. For filesystem capabilities, the
> CAP_SETFCAP capability is required.
> 
> In Robert's version, the different policies would each be
> implemented by a separate system call. In my version, the
> attribute handlers implement these rules.

I like the file permissions + user attributes, and then some definition of
system for system attributes.  In my implementation, I distinguish
"kernel" and "root", as the same distinction exists with securelevels and
integrity protection under BSD.  Mapping a capability to this behavior
makes sense -- perhaps it would be appropriate to define a new capability,
CAP_SYSEXTATTR to allow the overiding of system extended attribute
protection?

  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