On Wed, Apr 23, 2003 at 07:42:54PM +0100, Christoph Hellwig wrote:
> On Wed, Apr 23, 2003 at 02:35:59PM -0400, Stephen Smalley wrote:
> > The idea of using separate attribute names for each security module was
> > already discussed at length when I posted the original RFC, and I've
> > already made the case that this is not desirable. Please see the
> > earlier discussion.
>
> No. It's not acceptable that the same ondisk structure has a different
> meaning depending on loaded modules. If the xattrs have a different
> meaning they _must_ have a different name.
A .xyz file in my filesystem may mean one thing to application X, and
another thing to application Y - and quite possibly only application X
is able to make sense of the information in my .xyz file, even though
both applications use the .xyz suffix for their files.
We accept this ambiguity in file systems.
(We accept a similar possibility for ambiguity for UDP/TCP ports,
process names, etc. etc. etc.)
Even if I don't have application X installed, I can still backup and
restore my .xyz file. Because the tools use a common interface.
Why do extended attributes have to be different? (And who will maintain
the authorative registry over allocated xattr names?)
In my little mind it makes sense to have security information one
specific and well defined place. Then, depending on the kernel security
model, it can either make sense of the information, or it can not.
If I insert a disk with MLS labelled files in a TE system, I cannot
expect the system to magically enforce the MLS policy - but my tools
will still work. I think that sounds beneficial. In fact, for
disaster recovery, it sounds pretty damn convenient in my ears.
Tell me what I am missing here, please.
--
................................................................
: jakob@unthought.net : And I see the elder races, :
:.........................: putrid forms of man :
: Jakob Østergaard : See him rise and claim the earth, :
: OZ9ABN : his downfall is at hand. :
:.........................:............{Konkhra}...............:
-
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/
This archive was generated by hypermail 2b29 : Wed Apr 30 2003 - 22:00:11 EST