On Fri, 2008-02-29 at 13:07 -0800, Casey Schaufler wrote: > --- Trond Myklebust <trond.myklebust@xxxxxxxxxx> wrote: > > > On Fri, 2008-02-29 at 10:52 -0800, Casey Schaufler wrote: > > > So it sounds as if for an xattr protocol to be viable it would first > > > require that xattr semantics be generally accepted (POSIX definition > > > would suffice), that there be multiple implementations (Linux and Irix > > > could suffice should Irix still be around when POSIX is done), and > > > that there be a perceived need beyond that of the Lunitic Fringe > > > Security Community. > > > > The problem isn't that of supporting the naive user xattr model: we can > > almost do that within the existing 'named attribute' model of NFSv4. The > > problem is that of supporting the arbitrary "security metadata" that are > > allowed to have side-effects on the system behaviour, and that we appear > > to have thought was a good idea to overload onto the xattr interface. > > Hum. Security metadata was one of the justifications for the > original implementation of the xattr interface for XFS at SGI. > The implementation was intended to be generic and allow for > storage of data that impacts system behavior. No, it is not > overloading at all, it is really supposed to be used that way. > That's how it works on CXFS, which I know is still proprietary, > but which could become an open peer of NFS someday. Historical accidents change nothing to my argument. I still don't like to be confusing user xattrs (which is a _storage_ issue) and the security metadata (part of a _control_ protocol). Nor do I see a compelling need to repeat any design mistakes that CXFS might have made in this area... > Yes, I can see that having a specific interface reduces the > documentation required, and simplifies it as well. Unfortunately, > given the way that a secctx is defined for either SELinux or > Smack, and the fact that the relationships between secctx values > are defined independently on the server and client* it does not > appear that the interoperability issue has been addressed, or > even really acknowleged with the proposed scheme. Yes, the issue > of label translation has been acknowleged, but it appears to me > that a day one solution is required for the scheme to be useful. What would your expectation be for a SMACK-based client, if it mounts from a server that turns out to be running with an SELinux security model, or vice versa? 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
