Commits
Pavel Emelianov authored and Konstantin Khlebnikov committed 8f0518c1e0e
ve: Don't check for CAP_SETVEID - use more ... imagination This patch: The proposed check correctly detects the root in ve0. However, we lose the ability to create containers with some fancy tool, that has the CAP_SETVEID capability *only*, but we don't have such. The cap itself is declared to be obsoleted, but there's no need in rewriting vzctl in a rush - things will still work. If we'll want to manipulate audit caps from the vzctl we'll make it via features. Overall history: Don't ban CAP_AUDIT_XXX capabilities in container to make the dbus-daemon work. After two (maybe tree) days of brain storm me and Den finally gave birth to this solution. So... First of all AUDIT will be banned in container. Since dbus refused not to set audit caps we don't want it to mess with it in any case. Next step is to note, that CAP_AUDIT_CONTROL coincides with the CAP_VE_ADMIN, which is not that bad (besides, dbus doesn't try to set this one up) and we leave one alone. And finally - the CAP_AUDIT_WRITE, which coincides with the most delicate one - CAP_SETVEID. The latter one is explicitly dropped on container start and there's no way to set one (dbus tries this and fails) back. Simple "don't clear it" solution is too dangerous. TO handle *this* case we 1. replace all checks to capable(CAP_SETVEID) to more complicated, but still matching ve0's root only; 2. don't ban the CAP_SETVEID (== CAP_AUDIT_WRITE == the_one_dbus_needs); 3. remember, that this capability is present on ve startup and thus we automatically have the CAP_AUDIT_WRITE required by dbus; 4. carefully handle the case, when we enter container in do_env_create and try to call fairsched system calls. That's it. No fraud, just manual dexterity ;) Bug #117448