See if its worth supporting podman pre 4.3

[sHedC]

Describe the bug Podman won't start if version is pre 4.3 as --userns keep-id:uid=$ZWIFT_UID,gid=$ZWIFT_GID is not supported this impacts ubuntu 22.04 variants (including PopOS 22.04) which have end of life in 2032.

To Reproduce Steps to reproduce the behavior:

1. Install PopOS 22.04 with Podman
2. Install and run zwift

Expected behavior Look to supporting a previous version using --uidmap --gidmap or something else?

Additional context Not sure this will get supported will look into it.

[sHedC]

Seems replacing

--userns keep-id:uid=$ZWIFT_UID,gid=$ZWIFT_GID

with

--uidmap $ZWIFT_UID:0:1
--uidmap 0:1:$ZWIFT_UID
--gidmap $ZWIFT_GID:0:1
--gidmap 0:1:$ZWIFT_GID

Has the same effect, this would then map the container user to the host user-id and group provided and might work better so in the container the uid and group is always 1000 (user) but this maps to host id, not sure.

[sHedC]

Actually podman is working differently, I am now trying with a user that has a different id to 1000 and it seems i actually need to map to the container uid to make it work.

Also podman downloads the docker image for each user, not sure that can be shared.

Have to re-think podman running.

[netbrain]

https://docs.oracle.com/en/operating-systems/oracle-linux/podman/podman-ConfiguringStorageforPodman.html

Maybe leave config of podman and storage location up to the podman users who actually do run multiple users?

[perrin4869]

Yeah I doubt anyone running podman would want to share images between users

[bluesquall]

It looks like Pop!OS 24.04 is going to have a much more recent version of podman, I just don't have bandwidth to upgrade until after my next work trip. Debian stable already has podman 4.3.1.

I didn't mean to kick off a big effort, so please don't feel pressured to add & support this.

[sHedC]

Yes not worried about that its more about if your uid is NOT 1000 then zwift will fail to run in podman. Reason is to do with the way podman does rootless mapping. so the current logic is wrong anyway.

So lets say i am running zwift using a user that has a uid of 1001, what I actually have to do is tell podman to map the container 1000 to the current user 1001 and this is done by this, which tells podman to map container uid 1000 to host uid 1001

--userns keep-id:uid=1000,gid=1000

anything else actually won't work, if you use gid as 1001 then it set the container to add group 1001 but doesn't really do anything.

It would be possible to map additional host users/ groups to the container 1000, 1000 that requires using the --uidmap and --gidmap. I am just not sure what the use case is here. But using uidmap and gidmap can do exactly the same as userns.

[sHedC]

As it says which makes more sense the more I read.

keep-id:uid=200,gid=210 - 200:210 (Map user account to specified UID, GID value within container.)

So I need to change the logic so that userns is always 1000:1000 to match the container id's (not the host) or use the uidmap to the same effect.

if wanting to map a different host id to the container 1000:1000 then have to use uidmap and gidmap. Should be ok but not sure the reason.

[sHedC]

Getting more understanding of podman and the UID mapping, bascially with podman we run the container UID/GID as 1000 as it was built. However we need to map the Host UID/ GID to the container to use the host resources.

As of 4.3 this is done using the --userns keep-id:uid=1000,gid=1000

This causes podman to start with the correct container IDs and creates an automatic mapping to the logged in HOST ID's.

Whilst testing this I found that if my user id is not 1000 (i have two accounts in fedora for example) zwift did not start so I needed to modify zwift to map the host mappings to the container one then start the container with the correct ID's.

I found further items that can map custom groups but these features come in a later version of prodman than 4.3. Prior to 4.3 you needed to setup mappings manually on the host to intermediate groups then map the intermediate groups to the container. So seems that 4.3 really is the minimum without creating manual and hard to understand config on the host.

So it does not seem feasible to use pre 4.3 podman :(

I have created a new branch and pull request against this to update the README and also to fix the issue of starting Zwift with podman using an ID that does not match the containers.

[netbrain]

Not quite sure if I understood all of that. @hobeone do you have any take on this?

[hobeone]

Sort of, but I'd need to install podman to mess around with it and test it. Podman seems to be doing the "better" technical thing from a security perspective and this use case (sharing hardware / permissions within and without a container) kinda works against it.

I probably should have just kept my UID mapping request to myself given all of the churn it's caused :/

[netbrain]

We live and we learn and we're better off having done it than not.

[sHedC]

Don't be sorry, I wanted to understand it for ages as I use Podman all the time for developments. Podman are improving this, in short Containers are isolated in rootless mode and by default there is no access to the host.

By default podman maps the root of the container to the user id starting the container, however this for the use case we have where we run Zwift as a user (1000) won't work as you can't pass through X or Wayland Access properly. Anything else was complex and required both host updates and podman start updates to perform the mapping.

As of 4.3 podman introduces the userns keep-id to map the current host user to the same user in the container so if you user id is 1000 and the container is 1000 it is a one to one mapping. With the additional options to provide container uid/ gid this then maps the host uid with the requested container.

So if you have fedora with two user accounts the secnod account will be 1001 and in this case it will automatically map 1001 host to 1000 container. All done automatically.

In a later version they have started adding the ability to be more specific in terms of adding additional uid's and gid's with the container by --gidmap +1000:@1001:1 as an example but its not well documented and requires a later version than 4.3 so I ignored it.

Anway in short I can't easily make pre 4.3 work without writing up lots of manual mapping processes or using the same user id in the host to the container.

With this update it works for any host user against the container id of 1000 so people with one machine and multiple login accounts.

[netbrain]

Thank you for this thorough explanation, makes sense now :)