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?) every character that could be returned > by our getprocattr hook (which for us is pretty much any character thats > valid in a pathname -- though IIRC we forgot one). > > Anyway, I'm guessing (at least with pstools 3.2.5) that '(' is not one of > the valid characters. IIRC ps gives up when it sees a "non-valid" character. > > I wrote a trivial little lsm which just returns 'foobar' for any getprocattr. > > # cat /proc/2322/attr/current > unconstrained (subdomain) > foobar (foobar) > > # ps -Z -p 2322 > LABEL PID TTY TIME CMD > unconstrained 2322 ttyS0 00:00:00 bash Actually, no, it is the space preceding the open paren that is invalid; see this patch for the expanded allowed character set in procps 3.2.5: http://cvs.sourceforge.net/viewcvs.py/procps/procps/ps/output.c?r1=1.51&r2=1.52 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. -- Steve Beattie SUSE Labs, Novell Inc. <[email protected]> http://NxNW.org/~steve/
Description: PGP signature
- Prev by Date: Re: [-mm patch] include/net/ieee80211.h must #include <linux/wireless.h>
- Next by Date: Re: [PATCH] Fix cryptoapi deflate not handling PAGE_SIZE chunks.
- Previous by thread: Re: [patch 0/15] lsm stacking v0.3: intro
- Next by thread: Re: [patch 0/15] lsm stacking v0.3: intro