[Labeled-nfs] Current development prototype patches.

[Matthew N. Dodd]

James Morris wrote:
> On Fri, 3 Aug 2007, Matthew N. Dodd wrote:
>>I would like to ask opinions on a less EA centric mechanism for setting labels
>>from userland.  As we're pursuing a labeling solution that does not rely on
>>EAs for persistent storage (from the client's point of view) it becomes
>>difficult to shoehorn things so that userland tools work as expected.
> 
> 
> EAs are an established API for manipulating fs labels under Linux.  I 
> think it's good from a userland consistency point of view to maintain EAs 
> as the labeling API for NFS.  The user-visible API does not necessarily 
> need to match the mechanism used to transfer labels over the wire (indeed, 
> NFSv4 ACLS under Linux use EAs locally but not on the wire).
> 
> Perhaps I'm missing something -- can you provide an example of how you're 
> having to shoehorn things ?

Sure.  The NFS client has no EA code currently.  So I'd need to add 
stubs just to get to the point where I can fake out part of the EA 
namespace to translate calls to setattr/getattr over the wire.  This is 
somewhat annoying after all the talk about EAs being these pure abstract 
blobs that the kernel doesn't interpret.

Further, a well designed label set/get facility would make things much 
easier on the server side where file labels need to be changed by the 
kernel.  In an ideal world I'd just notify the filesystem that the inode 
label has been changed and the filesystem code would do the right thing 
to push the label to disk.

Currently the filesystem code has the "init a label" and "save the label 
to disk" operations all in one function, which isn't exactly how things 
should work either.  In an ideal world we'd generate a label up in the 
VFS and push it down to the filesystem from vfs_create().

-- 
Matthew N. Dodd <Matthew.Dodd at sparta.com>
Principal Engineer, ISSO, SRD