Allow specifying group

[wootpthomas]

Greetings,

I ran into an instance where I wanted to run a SCUBA instance on my domain-joined Linux machine with the docker socket (/var/run/docker.sock) mapped in from the host. I'm using this "main" container to orchestrate the creation and management of other sibling containers. Trouble is that my primary group is not the "docker" group, but something else that I'd rather not change. SCUBA is setting the "main" container to run with my user's UID and primary group GID. In my case means that this created container will not have write access to the docker socket due to my user's primary group not being docker.

One way around this is to run SCUBA as root, but that feels dirty.

I was thinking that another way could be to allow the user a command line option to tell SCUBA to use one of the user's secondary groups instead of the primary group.

Thoughts?
Paul

[JonathonReinhart]

Hi Paul. Let me make sure I have this straight:

• You have a domain-joined Linux machine (host)
  • Your user wootpthomas has some UID (e.g. 20251001) and some GID (e.g. 20252002) from realmd
  • Your user wootpthomas is also member of a supplementary group named docker with some GID (e.g. 700)
• On host: You use Scuba to first run an orchestration container (c_main)
  • You bind-mount /var/run/docker.sock into this container
  • In the container this file has uid=0, gid=700 with permissions allowing group access (e.g. UGO 0o660)
• In c_main: You want to use Scuba to run additional sibling containers by accessing the bind-mounted docker socket
  • You are unable to do so because in c_main, you are executing with uid=20251001 (wootpthomas), gid=20252002 (wootptomas), and no supplementary groups.

Is that correct?

Assuming so, it sounds like the main limitation is the last thing I mentioned: scubainit does not configure any supplementary groups; they are explicitly dropped:

scuba/scubainit/src/main.rs

Lines 232 to 237 in 33be5ed

	// Drop all supplementary groups. Must be called before setuid().
	// SAFETY: The setgroups() syscall accesses no memory when size is 0.
	// Calling setgroups(0, NULL) is explicitly supported.
	unsafe {
	libc_result(libc::setgroups(0, std::ptr::null()))?;
	};

Some ideas:

• You could write a root hook to change the permissions on /var/run/docker.sock -- But I think this would affect the actual socket outside of the container, so that's probably a bad idea.

• I think I would be open to a PR that adds support for supplemental groups

  • Add config in .scuba.yml for additional groups (names).
  • Add a new environment variable named SCUBAINIT_SUPPLEMENTAL_GIDS with a comma-separated list of GIDs.
  • Add code in scuba to look up those group names and pass the gids,
  • Add code in scubainit to parse those gids and pass them to setgroups() instead of null.

There may be an easier solution I'm not thinking of. Perhaps other Scuba power-users might have an idea.

[wootpthomas]

Yes, that more explicitly sums up what I'm seeing.

Perhaps a somewhat easier lift than supporting all supplementary groups would be to allow the user to specify a group to use (out of the user's supplementary group) and use that group instead of the primary group.

Paul

[JonathonReinhart]

allow the user to specify a group to use (out of the user's supplementary group) and use that group instead of the primary group.

I'm not sure that's a good idea: All files created in the container will be owned by $uid:$this_other_gid which would be surprising at a minimum and a security problem at worst.

[wootpthomas]

By using the feature to specify the group used with the requirement that the specified group must be in the user's existing supplementary groups, I can see where this could be surprising if the user has not looked at the SCUBA file. But doesn't a user have to initially look at a SCUBA file to look at the aliases and see what they do? I imagine that they would see a "group" key and that should trigger them to go look at the docs.

I did some more reading up on supplementary groups and stumbled on the newgrp command. This does exactly what I need it to do. From man newgrp:

The newgrp command is used to change the current group ID during a login session

Here I thought this was just for adding a user to a group! I was able to run newgrp docker to change my current session's primary group to the docker supplementary group and then run the SCUBA command and things ran without issue. Nice!

With learning about the newgrp command, I can not think of any scenario where having a SCUBA feature to specify to use a supplementary group of the current user would cause a security issue.

I still do think that having the ability to add one or more supplementary groups would be useful.

[JonathonReinhart]

With learning about the newgrp command, I can not think of any scenario where having a SCUBA feature to specify to use a supplementary group of the current user would cause a security issue.

When a user creates a file, it is created with the UID and GID of the user. On many systems, that GID is a "user private group" (UPG) so that even if umask is set to *0* and the group gets full access, data is not inadvertently shared with other users.

If you change the user's GID to one of their supplemental groups, files could be shared with all members of that supplemental group.

[wootpthomas]

Ah, I see what you mean. This would be a user that isn't aware that their group has changed if this feature were used. Gotcha.

I agree that changing the primary group in the container would be bad, better to support supplemental groups.

[fortenbt]

I started implementing this, and it seems pretty straightforward. Some of the thoughts/questions I've had while doing this are:

1. Does it only makes sense to add supplementary groups when changing the user (not running as root)?
2. Do we care about conflicting existing groups within the container for added supplementary groups? e.g. If GID 1001 already exists within the container as some named group that isn't equal to GID 1001 on the host, does it matter?
3. Do environment variables override config? I'm assuming this is already handled one way or the other with the other environment variables and I wanted to make sure whatever I did was correct.

I should also add here that we thought about if scuba should possibly automatically mirror all the user's supplemental groups within the container. I could see either way, but I am of the opinion that it's probably best practice to follow minimalist design to avoid conflict with any existing groups in a container and allow the user to build them up as desired.