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. :-))
> In addition, as far as I can tell, the point of bcapabilities (vx_bcaps)
> is to limit the entire set of capabilities available to a VM. This is in
> line with the change I suggest.
>
> cap-bound, instead of limiting capabilities, merely limits capabilities
> inherited automatically with superuser emulation. (Assuming
> !SECURE_NOROOT) This feature does trickle down to the vms and makes sense
> to be done on a system-wide basis.
>
> In short, this change makes capabilities work, for those of us who still
> use them actively.
I have no idea what that actually means. Care to elaborate?
> The patch can be found here.
> http://users.k12system.com/mrwizard/software/patch-vserver-cap_bound_set.diff
The only bug that I see is that we don't let guests modify vx_cap_bset at
this time, but
http://people.linux-vserver.org/~dhozac/p/k/delta-cap_bset-fix01.diff
should take care of that...
-- Daniel Hokka ZakrissonReceived on Mon Jun 16 21:27:32 2008