Joe Gooch wrote:
> See inline.
> Joseph Gooch
> Sapphire Suite Product Manager
> K12 Systems, Inc.
> (866) 366-9540
>> -----Original Message-----
>> From: Daniel Hokka Zakrisson [mailto:firstname.lastname@example.org]
>> Sent: Monday, June 16, 2008 4:27 PM
>> To: Joe Gooch
>> Cc: email@example.com
>> Subject: Re: [vserver] Capabilities in Vserver Kernels
>> Joe Gooch wrote:
>> > I have diagnosed what I believe to be an incorrect use of
>> > in virtual contexts. I believe the vx_mask_cap_bset function in
>> > kernel/vserver/context.c should mask based on vx_bcaps, not
>> > Rationale:
>> > vx_cap_vset is the capabilites set from /proc/sys/kernel/cap-bound,
>> > which is global for the system, not by VM. Using vx_bcaps
>> allows it
>> > to be set by vm.
>> Uh, no, it's the other way around. vx_bcaps can only be set
>> from the host.
>> The purpose of vx_cap_bset is to allow the guest to set
>> /proc/sys/kernel/cap-bound on its own, independently from the
>> host (obviously not to raise it).
>> (Also, VM is really not the right term. It's not virtual, and
>> it's not a machine. :-))
> VS then. :)
> OK, well if that's the intention, it's still not working.
> Host# cat /proc/sys/kernel/cap-bound
> (128 equates to CAP_SETUID)
> Host# vserver support exec cat /proc/sys/kernel/cap-bound
> Host# cat /etc/vservers/support/bcapabilities
That is perfectly fine. We don't mask vx_bcaps until it's used, which
means software like BIND9 works without modifications in a guest, as well
as gives you the ability to dynamically change the capabilities assigned
to a guest. So that guest won't be able to do anything requiring
> In fact, in examining the code, vx_cap_bset is only ever set from the
> calling context. It's never pulled from anywhere else, as far as I can
> tell. Bcapabilities are dumped directly into vx_bcaps.
... without the patch in my email, yes.
> As a side note, I spend a large amount of time searching for the proper
> way to use bcapabilities and ncapabilities and such, but could not find an
> explanation of what these were or what they were intended to be used for.
> It could be part of the wiki restructuring; I'm not sure. So my knowledge
> in this regard is based on the code without context.
> So now, vserver. I don't have an example of what it does unmodified
> (since I'm using this patch in production. And it does work. It makes
> the vserver behaviour consistent with the parent kernel), but here's what
> it does modified.
> Host /proc/sys/kernel/cap-bound is 128
> Bcapabilities is ~CAP_SYS_BOOT and ~CAP_AUDIT_WRITE (in addition to the
> others vserver drops):
> # vserver support exec getpcaps =
> Capabilities for `=': =
> My new root process is limited by bcapabilities...
> # execcap ' =eip cap_lease,cap_net_bind_service,cap_setpcap-eip ' vserver
> support exec getpcaps =
> Capabilities for `=': =
> But it's ALSO bounded by inheritable sets.
None of these are interesting, as they all show the per-process values. If
you'd actually try to use a capability that's not in vx_bcaps, you'd get
EPERM, as expected, since you need to have _both_. /proc/<pid>/status
shows the masked values, i.e. what's actually used by permission checks.
>> > The patch can be found here.
>> > et.diff
>> The only bug that I see is that we don't let guests modify
>> vx_cap_bset at this time, but
>> should take care of that...
> I wouldn't use this. I wouldn't want my guest to change it anyway. The
> fix here is the behavior of new processes and where and how they receive
> capabilities from the parent.
"Parent"? Process? The host?
-- Daniel Hokka ZakrissonReceived on Mon Jun 16 23:04:53 2008