[CRIU] [PATCH 4/5] cgroups: add support for c/r of the devices cgroup

Cyrill Gorcunov gorcunov at gmail.com
Mon Jun 6 09:54:30 PDT 2016


On Mon, Jun 06, 2016 at 03:20:16PM +0000, Tycho Andersen wrote:
> This one is a little big ugly, see comments for details. At some point we
> should invent a better way to do these special cases, since we have them
> for freezer, cpuset, and now devices. Perhaps something like fstype, where
> you can ask the cgroup how to restore itself.
> 
> Signed-off-by: Tycho Andersen <tycho.andersen at canonical.com>
> CC: Cyrill Gorcunov <gorcunov at openvz.org>
...
> @@ -1253,6 +1253,46 @@ static int prepare_cgroup_dir_properties(char *path, int off, CgroupDirEntry **e
>  				if (special)
>  					continue;
>  
> +				/* The devices cgroup must be restored in a
> +				 * special way: only the contents of
> +				 * devices.list can be read, and it is a
> +				 * whitelist of all the devices the cgroup is
> +				 * allowed to create. To re-creat this
> +				 * whitelist, we first deny everything via
> +				 * devices.deny, and then write the list back
> +				 * into devices.allow.
> +				 */
> +				if (!strcmp(e->properties[j]->name, "devices.list")) {
> +					CgroupPropEntry *pe = e->properties[j];
> +					char *old_val = pe->value, *old_name = pe->name;
> +					int ret;
> +
> +					/* A bit of a fudge here. These are
> +					 * write only by owner by default, but
> +					 * the container engine could have
> +					 * changed the perms. We should come up
> +					 * with a better way to restore all of
> +					 * this stuff.
> +					 */
> +					pe->perms->mode = 0200;
> +
> +					pe->name = "devices.deny";
> +					pe->value = "a";
> +					ret = restore_cgroup_prop(e->properties[j], path, off2);
> +					pe->name = old_name;
> +					pe->name = old_val;

IIRC, choosing device.allow or device.deny depends
on default stragegy. If it's "allow", then list
represent those which are not permitted to use
and reverse, no?


More information about the CRIU mailing list