RE: [vserver] Capabilities in Vserver Kernels

From: Daniel Hokka Zakrisson <>
Date: Mon 16 Jun 2008 - 23:04:42 BST
Message-ID: <51336.>

Joe Gooch wrote:
> See inline.
> Joseph Gooch
> Sapphire Suite Product Manager
> K12 Systems, Inc.
> (866) 366-9540
>> -----Original Message-----
>> From: Daniel Hokka Zakrisson []
>> Sent: Monday, June 16, 2008 4:27 PM
>> To: Joe Gooch
>> Cc:
>> Subject: Re: [vserver] Capabilities in Vserver Kernels
>> Joe Gooch wrote:
>> > I have diagnosed what I believe to be an incorrect use of
>> capabilities
>> > in virtual contexts. I believe the vx_mask_cap_bset function in
>> > kernel/vserver/context.c should mask based on vx_bcaps, not
>> vx_cap_bset.
>> >
>> > 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
> (128 equates to CAP_SETUID)
> Host# vserver support exec cat /proc/sys/kernel/cap-bound
> 128
> 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. (which is linked from

> [...]
> 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 `=': =
> cap_chown,cap_dac_override,cap_dac_read_search,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_net_bind_service,cap_sys_chroot,cap_sys_ptrace,cap_sys_tty_config,cap_lease+eip
> 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 `=': =
> cap_chown,cap_dac_override,cap_dac_read_search,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_sys_chroot,cap_sys_ptrace,cap_sys_tty_config+eip
> 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 Zakrisson
Received on Mon Jun 16 23:04:53 2008
[Next/Previous Months] [Main vserver Project Homepage] [Howto Subscribe/Unsubscribe] [Paul Sladen's vserver stuff]
Generated on Mon 16 Jun 2008 - 23:05:01 BST by hypermail 2.1.8