Re: [PATCH] Extended Attributes for Security Modules against 2.5.68

From: Valdis.Kletnieks@vt.edu
To: Chris Wright <chris@wirex.com>
Cc: lkml <linux-kernel@vger.kernel.org>,
	lsm <linux-security-module@wirex.com>
Subject: Re: [PATCH] Extended Attributes for Security Modules against 2.5.68
Date: Wed, 23 Apr 2003 15:28:07 -0400	[thread overview]
Message-ID: <200304231928.h3NJS73j002919@turing-police.cc.vt.edu> (raw)
In-Reply-To: Your message of "Wed, 23 Apr 2003 12:15:17 PDT." <20030423121517.C15094@figure1.int.wirex.com>

[-- Attachment #1: Type: text/plain, Size: 875 bytes --]

On Wed, 23 Apr 2003 12:15:17 PDT, Chris Wright <chris@wirex.com>  said:
> * Andreas Dilger (adilger@clusterfs.com) wrote:

> > The only reason to use a common "system.security" is if the actual data
> > stored therein was usable by more than a single security module.
> 
> Or, as mentioned, if you care to print out the label with standard
> fileutils.

The requirement that things like ls, find, cp and so on know where to look
for these things trumps any "purity of labels" arguments.

In addition, a case can be made that different modules *should* use the
same name - because that way when you're re-labelling a file system for
a new security module, you can actually *detect* old crufty conflicting
labels added by some previous module.

"Warning: file %s was already labelled with attribute %s"

If you do as Chris suggests, you can't implement this in a clean manner.

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]