From: Frank v W. <fv...@va...> - 2006-07-18 06:46:56
|
The problem turned out to be caused in userspace, for some odd reason the init on the gentoo disk image I'd nabbed did something that set its inheritable mask to ~0. Not sure if its doing it on purpose, and I still don't quite understand the code I quoted below, but it's not relevant to UML, so I'll ask about it elsewhere. Sorry for the noise. On Sun, Jul 16, 2006 at 02:05:31PM +0200, Frank v Waveren wrote: > On Sun, Jul 16, 2006 at 12:31:51PM +0200, Blaisorblade wrote: > > On Saturday 15 July 2006 17:23, Frank v Waveren wrote: > > > I was trying to limit some unecessary capabilities in a UML instance > > > with /proc/sys/kernel/cap-bound, but it turned out not to take. > >=20 > > To remove capabilities from the whole system (i.e. all processes) the= =20 > > recommended way wasn't to use lcap (or a similar program bundled with= =20 > > libcap)? > Yup, lcap is just an interface to /proc/sys/kernel/cap-bound. >=20 >=20 > > > The source of the problem (or at least something a bit of the way up > > > the garden path of the problem) is at security/commoncap.c:140 at the > > > top of cap_bprm_apply_creds(bprm, unsafe): > > > > > > void cap_bprm_apply_creds (struct linux_binprm *bprm, int unsafe) > > > { > > > /* Derived from fs/exec.c:compute_creds. */ > > > kernel_cap_t new_permitted, working; > > > > > > new_permitted =3D cap_intersect (bprm->cap_permitted, cap_= bset); > > > working =3D cap_intersect (bprm->cap_inheritable, > > > current->cap_inheritable); > > > new_permitted =3D cap_combine (new_permitted, working); > > > ... > > > > > > Here the new permitted set gets limited to the bits in cap_bset, which > > > is as it should be, but then the intersection of the of the current > > > and exec inheritable masks get added to that set, whereas as I > > > understand it, cap_bset should always be the bounding set. > > > > > > I've tried commenting out that bit and everything worked as I'd hoped > > > (I haven't done extensive testing, but bounding the caps worked, as > > > did suids and such). > > > > > > That doesn't explain why it works with those lines left in on a > > > non-UML kernel though, so I assume I'm missing something fundamental. --=20 Frank v Waveren Key fingerprint: BDD7 D61E fv...@va... 5D39 CF05 4BFC F57A Public key: hkp://wwwkeys.pgp.net/468D62C8 FA00 7D51 468D 62C8 |