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 > -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
