Oh, and I should just add that UML is a great pleasure to debug
compared to kernel-mode-linux. Thanks for the wonderful work everyone!
--
Frank v Waveren Key fingerprint: BDD7 D61E
[EMAIL PROTECTED] 5D39 CF05 4BFC
F57A
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'l
On Sun, Jul 16, 2006 at 09:24:36PM +0200, Blaisorblade wrote:
> On Sunday 16 July 2006 14:05, 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 capabilit
On Sunday 16 July 2006 14:05, 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 tu
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.
>
> To remove capabilities from the wh
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.
To remove capabilities from the whole system (i.e. all processes) the
recommended way wasn't to use lcap
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.
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_cred
