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. In the case of maclabels, where the "side-effect" is to describe and enable extra access control rules, then you have the potential for setting people up with a major interoperability problem. Using a dedicated interface for it instead of overloading a Linux-style xattr interface allows you to limit the scope of the documentation problem that you would otherwise have. 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
