Mon, 16 Jun 2008 15:34:57 -0400
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.
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.
The patch can be found here.
http://users.k12system.com/mrwizard/software/patch-vserver-cap bound set.diff
Take care!
-Joe
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.
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.
The patch can be
found here.
Take
care!