Re: [PATCH 0/4][RFC] NFSv3: implement extended attribute (XATTR) protocol

["J. Bruce Fields" <bfields@fieldses.org>]

On Mon, Oct 12, 2009 at 06:55:58PM -0400, Trond Myklebust wrote:
> On Mon, 2009-10-12 at 15:34 -0400, Peter Staubach wrote:
> > > So, is this a new side band protocol or an extension to NFSv3?
> > > 
> > 
> > This is a side band protocol designed to allow the setting
> > and getting of Linux style extended attributes.  They don't
> > quite match the Solaris style sub-files approach, but I
> > think could be implemented on top of the sub-files approach.
> 
> Sub-files are really a different kettle of fish, since they don't have
> any side-effects on the main file itself.
> 
> xattrs are basically three different sets of objects bundled into one
> set of syscall interfaces.
> 
>      1. There is a set of 'user' extended attributes, which are
>         basically arbitrary length named strings. Anyone with read
>         access to the file can read them, and anyone with write access
>         can set them. Setting or clearing a user attribute has no
>         side-effects on the parent file.

It does update the parent file's ctime, though.

--b.

>	  The most common usage for these
>         strings appears to be to annotate the file with search metadata
>         (c.f. beagle)...
>      2. There are a set of 'trusted' extended attributes. These are
>         similar to user attributes, in that they have no side-effects,
>         however you need to use a privileged process in order to set or
>         read them.
>      3. The 'system' and 'security' extended attributes are where all
>         hell breaks loose. These provide storage for things like posix
>         acls, and selinux security contexts. Setting or clearing these
>         attributes will almost certainly have side-effects on the parent
>         file itself, so you really want to be very careful with what you
>         stuff into them.
> 
> > > Is there some document describing the problem being solved?
> > > 
> > 
> > Not exactly, or at least, not that I've seen.  There is a need
> > to support general Linux style extended attributes over NFSv3
> > and NFSv4 prior to 4.2.  This will be used in the short term
> > to solve some of the base issues that are being addressed by
> > the Labeled NFS work currently underway in the IETF WG.  That
> > work is much more extensive and designed to be a better
> > solution, but we need something before that work will complete.
> > 
> > I am seeking to discover whether this will be a Linux to
> > Linux only solution always or whether other vendors might be
> > amenable to considering implementing this support.
> 
> I don't see how it can be anything but a Linux to Linux, single
> distribution only solution if you support setting and clearing 'system'
> and 'security' extended attributes, since there appears to be no method
> outlined here for negotiating which features the client and server
> support.
> Without such negotiation (or the requirement that the client and server
> be completely homogeneous), how do I, for instance, stop the
> 'restorecon' utility running on my client from breaking my mail server
> process running on a completely different machine when it decides to
> reset the 'security.selinux' label on my ~/mail folder?
> 
> Cheers,
>   Trond
>