linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jakob Oestergaard <jakob@unthought.net>
To: Christoph Hellwig <hch@infradead.org>,
	Stephen Smalley <sds@epoch.ncsc.mil>,
	Linus Torvalds <torvalds@transmeta.com>,
	"Ted Ts'o" <tytso@mit.edu>,
	Andreas Gruenbacher <a.gruenbacher@computer.org>,
	Stephen Tweedie <sct@redhat.com>,
	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: Thu, 24 Apr 2003 07:02:49 +0200	[thread overview]
Message-ID: <20030424050249.GC16519@unthought.net> (raw)
In-Reply-To: <20030423194254.A5295@infradead.org>

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}...............:

  parent reply	other threads:[~2003-04-24  4:50 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-04-23 17:52 [PATCH] Extended Attributes for Security Modules against 2.5.68 Stephen Smalley
2003-04-23 18:17 ` Christoph Hellwig
2003-04-23 18:25   ` Chris Wright
2003-04-23 18:45     ` Christoph Hellwig
2003-04-23 19:17       ` Stephen Smalley
2003-04-23 19:26         ` Christoph Hellwig
2003-04-23 19:52           ` Stephen Smalley
2003-04-23 20:20             ` Christoph Hellwig
2003-04-24 12:55               ` Stephen Smalley
2003-04-24 13:03                 ` Christoph Hellwig
2003-04-24 13:49                   ` Stephen Smalley
2003-04-24 18:36                     ` Chris Wright
2003-04-24 19:02                       ` Stephen Smalley
2003-04-24 19:40                         ` Andreas Dilger
2003-04-24 20:04                           ` Stephen Smalley
2003-04-24 20:47                           ` Chris Wright
2003-04-24 19:47                         ` Chris Wright
2003-04-24 20:07                           ` Stephen Smalley
2003-04-23 20:07           ` richard offer
2003-04-23 18:54     ` Andreas Dilger
2003-04-23 19:14       ` Stephen Smalley
2003-04-23 19:15       ` Chris Wright
2003-04-23 19:28         ` Valdis.Kletnieks
2003-04-23 19:40           ` Chris Wright
2003-04-23 19:49             ` Valdis.Kletnieks
2003-04-23 18:35   ` Stephen Smalley
2003-04-23 18:42     ` Christoph Hellwig
2003-04-23 18:59       ` Stephen Smalley
2003-04-23 19:09         ` Christoph Hellwig
2003-04-24  5:02       ` Jakob Oestergaard [this message]
2003-04-28 15:59       ` Stephen C. Tweedie

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20030424050249.GC16519@unthought.net \
    --to=jakob@unthought.net \
    --cc=a.gruenbacher@computer.org \
    --cc=hch@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@wirex.com \
    --cc=sct@redhat.com \
    --cc=sds@epoch.ncsc.mil \
    --cc=torvalds@transmeta.com \
    --cc=tytso@mit.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).