On Tue, Jan 08, 2008 at 05:05:35PM -0500, Dave Quigley wrote:
> xattrs are only the local Linux representation of a MAC attribute. For
> the purpose of interoperability we can't assume xattrs considering NFSv4
> doesn't contain them in the specification. We considered the named
> attributes but they fall short concerning file labeling. Instead we are
> working on adding another recommended attribute to the NFSv4
> specification to handle an opaque security label. For your purposes you
> can continue to think of them as extended attributes since that is the
> interface that Linux has chosen for security attributes. However, I
> don't see this functionality making its way into Linux any time soon
> since it will require a change to the NFSv4 standard and they are
> wrapping up the NFSv4.1 specification. I can't say how long it will be
> before NFSv4.2 starts up. Maybe future events will cause that to happen
> sooner than later.
I would hope that the existance of a good, well-documented
implementation is the important thing, and would make things go more
quickly.
--b.
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
_______________________________________________
Please note that [email protected] is being discontinued.
Please subscribe to [email protected] instead.
http://vger.kernel.org/vger-lists.html#linux-nfs
On Tue, 2008-01-08 at 17:25 -0500, J. Bruce Fields wrote:
> On Tue, Jan 08, 2008 at 05:05:35PM -0500, Dave Quigley wrote:
> > xattrs are only the local Linux representation of a MAC attribute. For
> > the purpose of interoperability we can't assume xattrs considering NFSv4
> > doesn't contain them in the specification. We considered the named
> > attributes but they fall short concerning file labeling. Instead we are
> > working on adding another recommended attribute to the NFSv4
> > specification to handle an opaque security label. For your purposes you
> > can continue to think of them as extended attributes since that is the
> > interface that Linux has chosen for security attributes. However, I
> > don't see this functionality making its way into Linux any time soon
> > since it will require a change to the NFSv4 standard and they are
> > wrapping up the NFSv4.1 specification. I can't say how long it will be
> > before NFSv4.2 starts up. Maybe future events will cause that to happen
> > sooner than later.
>
> I would hope that the existance of a good, well-documented
> implementation is the important thing, and would make things go more
> quickly.
>
> --b.
Rest assured we are working on keeping the implementation clean and in a
way that appeases the Linux-NFS Maintainers :) I am wondering if it
would be worth trying an incremental approach with this where we
concentrate solely on the "dumb" server at first getting that working
solidly and then work on the "smart" server. I've been reading through
RFCs for the past two weeks trying to solve an issue with the smart
server portion of labeled NFS.
Dave
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
_______________________________________________
Please note that [email protected] is being discontinued.
Please subscribe to [email protected] instead.
http://vger.kernel.org/vger-lists.html#linux-nfs