All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tony Jones <tonyj@immunix.com>
To: serge@hallyn.com
Cc: Steve Beattie <sbeattie@suse.de>, Tony Jones <tonyj@suse.de>,
	serue@us.ibm.com, lkml <linux-kernel@vger.kernel.org>,
	Chris Wright <chrisw@osdl.org>,
	Stephen Smalley <sds@epoch.ncsc.mil>,
	James Morris <jmorris@redhat.com>, Andrew Morton <akpm@osdl.org>,
	Michael Halcrow <mhalcrow@us.ibm.com>
Subject: Re: [patch 0/15] lsm stacking v0.3: intro
Date: Sat, 30 Jul 2005 21:13:34 -0700	[thread overview]
Message-ID: <20050731041334.GA20780@immunix.com> (raw)
In-Reply-To: <20050731034409.GA17120@vino.hallyn.com>

On Sat, Jul 30, 2005 at 10:44:09PM -0500, serge@hallyn.com wrote:
> > When I discussed this with Albert Cahalan, he *strongly* objected to
> > allowing whitespace in security contexts, as he felt it would break
> > scripts that parsed 'ps -Z' output.
> 
> Right, I thought this was actually a feature :)  This is how ps
> continues to show expected output under stacker.  Given naturally limited
> space, showing output for multiple modules may not be a good idea.  If
> you want more detail, you go to /proc/pid/attr/current...

OK. As long as you are aware of it, which it sounds like you are.

Serge, I think it should be documented as a known issue.

> Clearly this is limiting, but then so is the one line per process you
> get with ps - "fixing" that is obviously not acceptable.  Is there

Nothing jumps out at me.

> Is there any example where the current
> behavior is actually a problem - two modules which it makes sense to
> stack, which both need to give output under ps?

I don't know.  Isn't this the big negative against stacker, controlling
the composition?  pstools has clearly cast it's vote :-)

Tony

  reply	other threads:[~2005-07-31  4:18 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-07-27 18:17 [patch 0/15] lsm stacking v0.3: intro serue
2005-07-27 18:19 ` [patch 1/15] lsm stacking v0.3: introduce securityfs serue
2005-07-27 18:20   ` [patch 2/15] lsm stacking v0.3: add module * to security_ops serue
2005-07-27 18:21   ` [patch 3/15] lsm stacking v0.3: don't default to dummy_##hook serue
2005-07-27 18:23   ` [patch 4/15] lsm stacking v0.3: swith ->security to hlist serue
2005-07-27 18:24   ` [patch 5/15] lsm stacking v0.3: introduce security_*_value API serue
2005-07-27 18:24   ` [patch 6/15] lsm stacking v0.3: stacker documentation serue
2005-07-27 18:24   ` [patch 7/15] lsm stacking v0.3: actual stacker module serue
2005-07-27 18:25   ` [patch 8/15] lsm stacking v0.3: stackable capabilities lsm serue
2005-07-27 18:26   ` [patch 9/15] lsm stacking v0.3: selinux: update ->security structs serue
2005-07-27 18:26   ` [patch 10/15] lsm stacking v0.3: selinux: use security_*_value API serue
2005-07-27 18:27   ` [patch 11/15] lsm stacking v0.3: selinux: remove secondary support serue
2005-07-27 18:27   ` [patch 12/15] lsm stacking v0.3: hook completeness verification script serue
2005-07-27 18:28   ` [patch 13/15] lsm stacking v0.3: seclvl: update for stacking serue
2005-07-27 18:28   ` [patch 14/15] lsm stacking v0.3: fix security_{del,unlink}_value race serue
2005-07-27 18:28   ` [patch 15/15] lsm stacking v0.3: stacking for digsig serue
2005-07-27 19:34 ` [patch 0/15] lsm stacking v0.3: intro James Morris
2005-07-27 19:37   ` James Morris
2005-08-03 16:45     ` [PATCH] Stacker - single-use static slots serue
2005-08-03 17:57       ` Chris Wright
2005-08-03 19:27         ` serue
2005-08-03 19:45           ` Chris Wright
2005-08-03 20:31             ` serge
2005-08-05 15:55       ` James Morris
2005-08-05 17:27         ` serue
2005-08-05 17:34           ` serue
2005-08-10 14:45         ` serue
2005-08-11  7:42           ` James Morris
2005-08-11 21:22             ` serue
2005-08-11 23:02               ` James Morris
2005-07-27 19:54   ` [patch 0/15] lsm stacking v0.3: intro serue
2005-07-30  5:07 ` Tony Jones
2005-07-30 19:02   ` serge
2005-07-30 20:18     ` Tony Jones
2005-07-31  3:22       ` Steve Beattie
2005-07-31  3:44         ` serge
2005-07-31  4:13           ` Tony Jones [this message]
2005-07-31 13:37             ` serge
2005-07-31  3:53       ` serge

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=20050731041334.GA20780@immunix.com \
    --to=tonyj@immunix.com \
    --cc=akpm@osdl.org \
    --cc=chrisw@osdl.org \
    --cc=jmorris@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mhalcrow@us.ibm.com \
    --cc=sbeattie@suse.de \
    --cc=sds@epoch.ncsc.mil \
    --cc=serge@hallyn.com \
    --cc=serue@us.ibm.com \
    --cc=tonyj@suse.de \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.