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 Zakrisson