Skip to content
This repository was archived by the owner on Feb 8, 2021. It is now read-only.
This repository was archived by the owner on Feb 8, 2021. It is now read-only.

Additional groups handling broken when working with runv and docker #250

@wrouesnel

Description

@wrouesnel

In exec.c:265:

	// append additional groups to supplementary groups
	int i;
	reallocgroups = realloc(groups, sizeof(gid_t) * (ngroups + exec->nr_additional_groups));
	if (reallocgroups == NULL)
		goto fail;
	groups = reallocgroups;
	for (i = 0; i < exec->nr_additional_groups; i++) {
		fprintf(stdout, "try to find the group: %s\n", exec->additional_groups[i]);
		struct group *gr = hyper_getgrnam(exec->additional_groups[i]);
		if (gr == NULL) {
			perror("can't find additional group");
			goto fail;
		}
		groups[ngroups] = gr->gr_gid;
		ngroups++;
	}

This stanza of code is broken when using runv with docker - the problem is docker passes in a huge stanza of additional groups by default from the user running it (docker 1.12.1 at least):

I0106 16:43:13.550083   25707 vm_console.go:46] SB[vm-rDTiYKRrYK] [CNL] call hyper_new_container, json {"id":"1fa52cef9d6a715e905ae2c07e178f31ca87671a0c706f690a1f973717b2286e","rootfs":"rootfs","image":"1fa52cef9d6a715e905ae2c07e178f31ca87671a0c706f690a1f973717b2286e","process":{"id":"init","additionalGroups":["0","1","2","3","4","6","10","11","20","26","27"],"terminal":true,"stdio":1,"args":["sleep","10"],"envs":[{"env":"PATH","value":"/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"},{"env":"HOSTNAME","value":"1fa52cef9d6a"},{"env":"TERM","value":"xterm"}],"workdir":"/"},"restartPolicy":"never","initialize":false}

Obviously none of these groups exist in the client container, so the lookup fails and the group startup fails.

Probably the way this needs to be handled is do the lookup, and if it fails, try a string to int conversion, and if that succeeds use the integer number without the lookup. If both succeed for some reason, then fail.

There's a secondary issue which is a failure in this part of the code does not cleanly message back to the runv containerd daemon, so docker gets stuck waiting for a container to start without failing.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions