On Fri, 2008-02-29 at 10:52 -0800, Casey Schaufler wrote:
quoted text
> 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

--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/