scripts/container.sh: support podman on macOS

[stweil]

The default user and group IDs on macOS are different from those used on Linux, so add the expected ones explicitly.

[AiyionPrime]

@stweil maybe you could start a discussion about your goals and approaches to achieve them with @hafu, who attempted sth. similar in #2868.

[stweil]

The goal is very simple: the script should work.

The container creates a user "gluon". That user is the first one in a Linux environment which assigns UID 1000 and GID 1000. "gluon" must have r/w access to the gluon directories from outside. This can be achieved by mapping UID and GID of the user who is running the script to 1000 inside the container. See documentation for --userns for more information.

Without my patch a user with a UID != 1000 cannot use the script because then the container's "gluon" user would not have the same rights like the outside user. This is always a problem on macOS, but I expect that there would also be a similar problem on Linux.

[neocturne]

This change makes sense, but looking at the man page, it seems that the extended keep-id syntax was only introduced recently, breaking support for Podman on Ubuntu 22.04 and Debian Stable.

I managed to get a similar effect by replacing --userns=... with --uidmap=1000:0:1 --uidmap=0:1:999 --gidmap=1000:0:1 --gidmap=0:1:999. Not sure if there's a better solution...

[hafu]

The suggestion will indeed not work on Ubuntu 22.04 and return the error: Error: unrecognized namespace mode keep-id:uid=1000,gid=1000 passed

---

Using the suggested approach above: --uidmap=1000:0:1 --uidmap=0:1:999 --gidmap=1000:0:1 --gidmap=0:1:999 does not work for me:

$ id
uid=1001(ubuntu) gid=1001(ubuntu) groups=1001(ubuntu),4(adm),20(dialout),24(cdrom),25(floppy),27(sudo),29(audio),30(dip),44(video),46(plugdev),119(netdev),120(lxd)
$ ./scripts/container.sh
...
Error: error creating container storage: error creating an ID-mapped copy of layer "63e29016d54128596c149fd94e94a725ca7e47b73b49dd1aff1ee19c858cc591": exit status 1: error during chown: error mapping container ID pair idtools.IDPair{UID:1001, GID:1001} for "usr/local/bin/editorconfig-checker" to host: Container ID 1001 cannot be mapped to a host ID 

I assume it is caused by the usernamespace mapping (subuid, subgid).

---

I don't see here any easy solution without involving the current UID (id -u) and GID (id -g) of the executing user. What do you think about my suggested approach (#2868), to pass the UID and GID of the current executing user as build argument? I assume this will fix the issues in MacOS and also works with Docker as container environment.

[stweil]

@NeoRaider, thank you for pointing out that my change requires a recent podman and won't work with Debian stable or Ubuntu LTS. @AiyionPrime, I suggest to merge PR #2868 which should work with all current podman versions and which also addresses docker. Therefore I close my own pull request.

[neocturne]

I actually like the podman-specific solution better than #2868, as it doesn't require building the container specifically for a single UID/GID.

[neocturne]

Hmm, is there any reason why we need the build user to be in /etc/passwd at all? The --userns=keep-id should work fine if /gluon is mounted from outside of the container, even if it doesn't match the original owner of /gluon in the container image. So I'm wondering what issue this PR actually tried to solve.

[stweil]

That's correct. Removing the gluon user from Dockerfile and using --userns=keep-id works fine and looks like the simplest fix. I now have created a new pull request #2870.