Scuba on OSX fails to run Debian-based images

[JonathonReinhart]

Picking up the conversation from here:

debian images are stuck on something that appears related to #109 but other images like alpine:latest seem to work.

They fail with

scubainit: Warning: GID 20 already exists in /etc/group
scubainit: Group "staff" already exists with different gid in /etc/group

For anyone who wants a quick and dirty fix just use RUN groupdel staff

[JonathonReinhart]

Regarding this output:

scubainit: Warning: GID 20 already exists in /etc/group
scubainit: Group "staff" already exists with different gid in /etc/group

(This needs to be documented) To try to be as transparent as possible, scuba will try to run the container with the same user(id|name) and group(id|name) as used on the host:

• https://github.com/JonathonReinhart/scuba/blob/v2.10.0/scuba/scuba.py#L193-L198
• https://github.com/JonathonReinhart/scuba/blob/v2.10.0/scubainit/scubainit.c#L564-L592
• https://github.com/JonathonReinhart/scuba/blob/v2.10.0/scubainit/scubainit.c#L655-L662

The goal is that would print the same thing inside the container as it does on the host:

$ echo "uid=$(id -u)($(id -un)) gid=$(id -g)($(id -gn))"

Because the images can have anything in /etc/passwd or /etc/group, the add_user() and add_group() functions are pretty conservative. When there are conflicts, they abort.

The behavior when a matching UID or GID already exists was relaxed (changed to a Warning) in #139. @mpdude's rationale:

I think we could safely proceed in this case; Linux should be able to deal with multiple /etc/passwd (and /etc/group, FWIW) entries pointing to the same numerical ID.

The result of getgrgid() (lookup group by GID) and getpwuid() (lookup user by UID) become a little ambiguous, but it's probably not a problem.

---

What we have here, however, is the converse problem: An existing group entry with the same name. I'm assuming that on OSX, users must run with a default primary group named staff with GID 20.

However, on Debian, /etc/group looks like this:

dialout:x:20:
staff:x:50:

This is more difficult to deal with. Do we change the existing staff entry to be GID 20? Will this break anything in the image?

[JonathonReinhart]

From @christheyankee on #196 (comment):

It works fine if you delete the staff group. I've tested this pretty extensively including exposing ports, interacting with daemons, and using some pretty cursed proprietary software. Scuba hasn't died on any of it.

[retu2libc]

I don't like the idea of messing with GIDs. From the man page of groupmod for the -g flag

Any files that have the old group ID and must continue to belong to GROUP, must have their group ID changed manually.

With that in mind I think it might make more sense to rename the group on the container and clearly display a warning that this is happening.