Quoting Tony Jones ([EMAIL PROTECTED]):
> 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.
Ok.
> > Clearly this is limiting, but then so is the one line per process you
> > get with ps - "fixing" that is obviously not
On Sat, Jul 30, 2005 at 10:44:09PM -0500, [EMAIL PROTECTED] 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 featu
Quoting Tony Jones ([EMAIL PROTECTED]):
> > Yes, after I added the unlink function, it started to seem that the
> > special cases for !CONFIG_SECURITY_STACKER wouldn't be any faster than
> > the stacker versions. They still might be, but I'll have to think about
> > it. If I just ditch those, the
Quoting Steve Beattie ([EMAIL PROTECTED]):
> On Sat, Jul 30, 2005 at 01:18:52PM -0700, Tony Jones wrote:
> > # cat /proc/2322/attr/current
> > unconstrained (subdomain)
> > foobar (foobar)
> >
> > # ps -Z -p 2322
> > LABEL PID TTY TIME CMD
> > unconstrained
On Sat, Jul 30, 2005 at 01:18:52PM -0700, Tony Jones wrote:
> Of more concern is ps -Z (pstools).
>
> We had to have the pstools maintainer extend the set of characters that it
> considered valid from the getprocattr.I forget the details but IIRC he
> wanted to know (for ?documentation?) ever
Hi Serge
> > 5) /*
> > * Workarounds for the fact that get and setprocattr are used only by
> > * selinux. (Maybe)
> > */
> >
> > No complaints on selinux getting to avoid the (module), they are intree.
> > Just a FYI that SubDomain/AppArmor uses these hooks also.
>
> And is it ok with using
Quoting Tony Jones ([EMAIL PROTECTED]):
Thanks, Tony. I'll address each of these in the next patchset. Just
two things I wanted to actually converse about:
> 5) /*
> * Workarounds for the fact that get and setprocattr are used only by
> * selinux. (Maybe)
> */
>
> No complaints on selinux
On Wed, Jul 27, 2005 at 01:17:32PM -0500, [EMAIL PROTECTED] wrote:
Hi Serge.
A few trivial things I noticed whilst writing some internal documentation
on Stacker. Nothing deep here, but thought I'd pass them along.
I'll try to actually try out the code next week.
I made these notes as I was go
Thanks, James. I'll give this a shot and send out performance results
this weekend or next week.
thanks,
-serge
Quoting James Morris ([EMAIL PROTECTED]):
> On Wed, 27 Jul 2005 [EMAIL PROTECTED] wrote:
>
> > if interested in the performance results. I am certainly interested in
> > ways to furt
On Wed, 27 Jul 2005 [EMAIL PROTECTED] wrote:
> if interested in the performance results. I am certainly interested in
> ways to further speed up security_get_value.
What about having a small static array of security blob pointers for the
common case (e.g. SELinux + capabilities + perhaps someth
On Wed, 27 Jul 2005, James Morris wrote:
> Calls to security_get_value() etc. can then be very fast and simple for
> the common case, where the security blob is a pointer offset by an index
> in a small array. The arbitrarily sized hlist would then be a fallback
> with a higher performance hit
Hi,
The set of patches to follow introduces support for stacking LSMs. This
is its third posting to lkml. I am sending it out in the hopes of
soliciting more widespread feedback and testing, with the obvious eventual
goal of mainline adoption.
Any feedback from people actually using this patch
12 matches
Mail list logo
