[Labeled-nfs] Current development prototype patches.

[Trond Myklebust]

On Mon, 2007-08-06 at 12:33 -0700, Casey Schaufler wrote:
> --- Trond Myklebust <trond.myklebust at fys.uio.no> wrote:
> 
> > On Sat, 2007-08-04 at 19:51 +0100, Christoph Hellwig wrote:
> > > On Sat, Aug 04, 2007 at 11:38:06AM -0700, Casey Schaufler wrote:
> > > > I agree. EAs over NFS are not very hard. Have you seen the SGI published
> > > > xattr extension? It's not large or particularly complex, and it has 
> > > > about 10 years exposure in the Unix environment.
> > > 
> > > It's extremly nice.  And SGI even released the xdr en/decoding files
> > > under GPL a while ago.  A lot nicer than either the SUN NFSv3 ACL
> > > extensions or the whole subfile bullshit added to NFSv4.
> > 
> > Ugh. Yet another RPC sideband protocol?
> 
> Your point being?

That it should hardly be breaking news to anyone that this type of
sideband protocol sucks: the NLM, quota and the various ACL sideband
protocols provide ample evidence for why.

They are firewall-unfriendly: in particular, they usually require
ungainly extensions to the basic RPC protocol in the form of the
portmapper. We already got rid of that crap for NFSv4.

They add significant latency: The fact that you have a sideband protocol
instead of integrating it into the protocol means that you cannot use
optimisations such as NFSv4's COMPOUND to send the EA request as part of
the LOOKUP/OPEN/READDIR/whatever operation that you want to check the
protection status of. Instead you are forced to make another
(synchronous!) RPC request to the server in order to get the information
you need.
Your processes may be "safe", but they will run like treacle.

They add complexity: they are not part of the protocol, yet they add
conditions to the protocol. For instance, there is the issue of the
interaction of EAs with delegations, mandatory locks, share modes,...

All in all, they are a band-aid at best, and a bloody nuisance at worst.

Trond