Hi,

(Apologies, my last e-mail I think I accidentally sent to Erik, not the list; missing bits quoted below)

OK, I did not realize that the Remap* commands used --userns behind the scenes, I thought they used --uidmap and --gidmap.

That brings me back to my original need, which I'll reiterate:

"When using a regular host user to run a rootless container, map the container user as the host user."

That's really basic, right? Surely works without PodmanArgs already.

My only addition to that is: "If the container user is root (or sudoed to root), allow it to drop privileges so it can install apt packages."

Still sounds really basic, and where I work, it's really common. If there's problems, we exec into a deployed container and install some troubleshooting tools with apt that the minimalistic image doesn't contain by default. Based on previous discussions, the apt privilege drop needs one extra subordinate UID/GID to be available.

While I'm currently using the Remap* options to achieve these, I'm not married to them – they're just the first thing that I got to work. 

I've used PodmanArgs before, but in each case only as a stopgap measure while waiting for an option to appear in Quadlet.

So, hopefully my final question in this thread: is this "map user and allow dropping privileges" scenario doable with the Quadlet UserNS option, or do I need to open an issue?

Begin forwarded message:

From: Erik Sjölund <erik.sjolund@gmail.com>
Date: Tuesday, Sep 05, 2023 at 10:37 AM
To: Me <jklaiho@iki.fi>
Subject: [Podman] Re: What to use instead of RemapUsers/RemapUid/RemapGid in Quadlet now?

Hi,

Yeah, I'm fairly sure that would work, but am I to understand from your reply
that it is not possible to achieve with the UserNS quadlet option the things that the Remap* quadlet options did?

Correct. It's not possible.

If we just look at the use of --uidmap there is an enormous amount of
possibilities of how to map those.
Each container UID can be mapped to an arbitrary "intermediate UID"
but the mappings must be unique. By that I mean that different
container UIDs must not be mapped to the same intermediate UID. Also
different intermediate UIDs must not be mapped to the same container
UID. The number of possible ways of providing --uidmap corresponds to
a factorial in mathematics.

See how n! grows with n:
https://en.wikipedia.org/wiki/Factorial

The argument --userns=keep-id does not carry so much information. For instance
--userns=keep-id:uid=$uid,gid=$gid
can only be provided one time and has two numbers.

Another option to consider is
--userns=auto
but that option is quite different from --uidmap.
It provides different functionality.
The situation is a bit similar to static IP addresses vs dynamic IP
addresses in DHCP.

I see there is some discussion in
https://github.com/containers/podman/issues/17984
and
https://github.com/containers/podman/pull/17961

Erik




On Mon, Sep 4, 2023 at 9:46 PM jklaiho@iki.fi <jklaiho@iki.fi> wrote:

Hi Erik,

Yeah, I'm fairly sure that would work, but am I to understand from your reply that it is not possible to achieve with the UserNS quadlet option the things that the Remap* quadlet options did?

If so, why on earth did the Remap* options go away if a) they're still fully supported 'podman run' command-line options, and b) they serve a legit use case that UserNS doesn't fill?


- JK




On Monday, Sep 04, 2023 at 10:36 PM, Erik Sjölund <erik.sjolund@gmail.com> wrote:
I think the directive "PodmanArgs" can be used to set podman arguments
that don't have any
container option counterpart.
See man page:
https://docs.podman.io/en/latest/markdown/podman-systemd.unit.5.html

Maybe something like this could work?
PodmanArgs=--uidmap 0:0:1 --uidmap 100:1:1 --gidmap 0:0:1 --gidmap 65534:1:1
(untested)

Erik

_______________________________________________
Podman mailing list -- podman@lists.podman.io
To unsubscribe send an email to podman-leave@lists.podman.io