Rootless podman mount capabilities
by Lewis Gaul
Hi,
I'm trying to understand something about how capabilities in rootless
podman work.
How does rootless podman have the capability to set up container mounts
(such as cgroup mounts) given a privileged container itself doesn't? Does
podman deliberately drop caps, or somehow get elevated privileges to do
this?
This is the process tree podman sets up (where bash is the container
entrypoint here):
systemd(1)---conmon(1327421)---bash(1327432)
I'm assuming it's conmon that sets up the container's mounts (via runc in
this case), which is a process running as my user (rootless). How is it
that conmon has the capabilities required (SYS_ADMIN?) to create the
container's cgroup and sysfs mounts but within the container itself this is
not possible?
Thanks for any insight!
Lewis
2 months, 2 weeks
Why do use podman machine on Mac?
by Mehdi Haghgoo
The container experience with podman machine on Windows and mac is not optimal because the containers are slow. Mac is a Linux-based OS. So, why can't we create native containers on it as we do on Linux?
That applies to WSL. It's kind of Linux. Why cannot we create native Linux containers on it without resorting to Podman machine and podman clients?
2 months, 3 weeks
Re: Why do use podman machine on Mac?
by Jason Greene
That’s right Darren. The short answer is “containers are Linux”. The
longer answer is you need two key elements: a Kernel name-spacing facility,
and second a user-land ecosystem. On the former MacOS doesn’t have
something comparable. The closest is App Sandbox, but that is primarily a
syscall/ permission filtering mechanism (something also important for
containers, but only part of the problem). On the latter, this is what we
know of as containers, the user-land is the OS without the kernel, and as
such is very much tied to the kernel implementation. Darwin libraries and
apps use a different ABI and syscall interface than Linux, so basically
every container you use today would be incompatible even if there was
kernel support.
This is the situation with Windows containers (not to be confused with
using Podman on Windows or other container envs that run Linux containers).
Windows containers have kernel support and a win32 user-land, so to produce
them you have to port everything in the image to be native windows code.
They are useful but not anywhere near as predominant, since a big part of
the value is the portability a Linux container brings.
In contrast, WSL2 does run a Linux kernel in a shared VM, and internally it
is using Linux namespaces itself, with all distributions of a user sharing
the same Kernel. They ultimately abandoned the previous syscall emulation
approach since the NT kernel and Linux are just too different and the
behaviors don’t map cleanly. We leverage WSL2 for the Podman on Windows
implementation.
On Sep 7, 2023, at 11:51 AM, Darren Dupre <darren.dupre(a)gmail.com> wrote:
OS X has a Mach kernel and a BSD user land. Don’t think Apple is interested
in adding containers framework to that. I guess someone could write a
kernel extension but it’s a niche use case.
WSL 2 uses a real Linux kernel doesn’t it? But it’s still a VM inside of
Hyper V so I don’t think the performance is any different. WSL 1 is a posix
emulation with binary compatibility but no container support under the
hood.
Correct me if I'm wrong about that.
- Darren
On Thu, Sep 7, 2023 at 11:19 Mehdi Haghgoo via Podman <
podman(a)lists.podman.io> wrote:
> The container experience with podman machine on Windows and mac is not
> optimal because the containers are slow.
> Mac is a Linux-based OS. So, why can't we create native containers on it
> as we do on Linux?
>
> That applies to WSL. It's kind of Linux. Why cannot we create native Linux
> containers on it without resorting to Podman machine and podman clients?
>
>
> _______________________________________________
> Podman mailing list -- podman(a)lists.podman.io
> To unsubscribe send an email to podman-leave(a)lists.podman.io
>
_______________________________________________
Podman mailing list -- podman(a)lists.podman.io
To unsubscribe send an email to podman-leave(a)lists.podman.io
2 months, 3 weeks
Fwd: Re: What to use instead of RemapUsers/RemapUid/RemapGid in Quadlet now?
by jklaiho＠iki.fi
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?
- JK
> Begin forwarded message:
>
> From: Erik Sjölund <erik.sjolund(a)gmail.com (mailto:erik.sjolund@gmail.com)>
> Date: Tuesday, Sep 05, 2023 at 10:37 AM
> To: Me <jklaiho(a)iki.fi (mailto: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(a)iki.fi <jklaiho(a)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(a)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
2 months, 3 weeks
HELP! recover files from a deleted container
by Alvin Thompson
Help!
Is there any way to recover files from a deleted container? Long story short, I found the behavior of `podman network rm -f` unexpected, and it wound up deleting most of my containers. One in particular had a month of work in it (I was using it as a development environment), and it turns out only part of it was backed up. I’m desperate!
This is Podman for Windows, so most of the files on the “host” are in the WSL environment. I can get into that no problem with `wsl -d podman-machine-default`.
As an added wrinkle, my default connection was `podman-machine-default-root`, but I was was not running Podman rootful. I’m not sure this is particularly relevant.
grep-ing for strings which are unique to the development environment shows one hit in Windows, in %HOME%/.local/containers/podman/machine/wsl/wsldist/podman-machine-default/ext4.vhdx - which I assume is the file system for the WSL layer itself. I made a copy of it.
A grep within WSL itself doesn’t show so any hits, so it’s possible the files were deleted as far as WSL is concerned. I tried searching for an EXT4 undelete tool, but the only one I found (extundelete) is from 10+ years ago and doesn’t appear to work anymore.
I haven’t stopped WSL (I’m using /tmp as a staging area) or restarted the computer.
I’m at wit’s end. I really don’t know where to begin or look to recover these files, which I really, really need. Any recovery suggestions (no matter how tedious) would be welcome.
I know it’s too late to change now, but man, the behavior of `podman network remove` is unexpected.
Thanks,
Alvin
2 months, 3 weeks
What to use instead of RemapUsers/RemapUid/RemapGid in Quadlet now?
by jklaiho＠iki.fi
I'm running a bunch of rootless Podman containers. I noticed that the RemapUsers, RemapUid and RemapGid options (and possibly others that I haven't used) disappeared from the documentation of podman-systemd.unit in 4.5.0.
I barely and partially understood what the options did in the 4.4.0 days when we started using them, but got them working through trial and error.
Here's what we have across the board right now in our Quadlet generators. They still work in 4.5.0, but I'm assuming they'll go away eventually:
RemapUsers=manual
RemapUid=0:0:1
RemapUid=100:1:1
RemapGid=0:0:1
RemapGid=65534:1:1
With the 0:0:1 options, the root user/group inside the containers are mapped to the regular (non-root) host user/group. We need this, since the container bind mounts volumes from the host and must appear to the host as the regular user while doing so.
The 100:1:1 and 65534:1:1 options have to do with the special _apt user in Debian-based containers; apt drops privileges to that user in some circumstances. I couldn't tell you why remapping those are needed, but not having them caused problems when installing packages inside the containers.
What Quadlet options in Podman >=4.5.0 would be equivalent to the above legacy options?
2 months, 3 weeks
After reboot, Container not responding to connection requests
by Jacques Jessen
Running Podman as root and created a container for Symantec's HSM Agent.
When manually started, it reports as working:
[root@PoC ~]# podman ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
b53be5503ca7 localhost/symantec_hsm_agent:2.1_269362 catalina.sh run 4 minutes ago Up 4 minutes 0.0.0.0:8080->8080/tcp, 0.0.0.0:8082->8082/tcp, 0.0.0.0:8443->8443/tcp symhsm_agent
[root@PoC ~]# podman stats
ID NAME CPU % MEM USAGE / LIMIT MEM % NET IO BLOCK IO PIDS CPU TIME AVG CPU %
b53be5503ca7 symhsm_agent 3.55% 216MB / 4.112GB 5.25% 1.93kB / 1.09kB 249.2MB / 0B 29 3.759969275s 3.55%
You can successfully access the 8080, 8082, 8443 ports with a browser.
However, if the server is rebooted, while Podman will show results as above that it is working, from a browser you will be told:
ERR_CONNECTION_TIMED_OUT
If you manually Stop and Start the container, you can successfully access the 8080, 8082, 8443 ports with a browser.
Given there's no change in the configuration, this feels like there's a timing issue with the initial start. I used the Podman provided response to create the Service file:
[root@PoC ~]# podman generate systemd --new --name symhsm_agent
# container-symhsm_agent.service
# autogenerated by Podman
[Unit]
Description=Podman container-symhsm_agent.service
Documentation=man:podman-generate-systemd(1)
Wants=network-online.target
After=network-online.target
RequiresMountsFor=%t/containers
[Service]
Environment=PODMAN_SYSTEMD_UNIT=%n
Restart=on-failure
TimeoutStopSec=70
ExecStart=/usr/bin/podman run \
--cidfile=%t/%n.ctr-id \
--cgroups=no-conmon \
--rm \
--sdnotify=conmon \
--replace \
-d \
--name symhsm_agent \
-p 8443:8443 \
-p 8082:8082 \
-p 8080:8080 \
-v /opt/podman/:/usr/local/luna symantec_hsm_agent:2.1_269362
ExecStop=/usr/bin/podman stop \
--ignore -t 10 \
--cidfile=%t/%n.ctr-id
ExecStopPost=/usr/bin/podman rm \
-f \
--ignore -t 10 \
--cidfile=%t/%n.ctr-id
Type=notify
NotifyAccess=all
[Install]
WantedBy=default.target
Having to manually login and restart the container kind of defeats the purpose.
Thoughts and feedback appreciated.
3 months
