January 2024 - Podman - Podman List Archives

processes running in a podman container are visible on the host
by Matthias Apitz 17 Jan '24

17 Jan '24

I've built an own podman image which boots a SuSE Linux, starts a PostgreSQL dataserver and a SSH daemon to login into. The end of the Dockerfile says: ... # Start PostgreSQL server and SSH daemon on container start # COPY initSunRise.sh /usr/local/bin/initSunRise.sh RUN chmod 0755 /usr/local/bin/initSunRise.sh RUN mkdir /home/sisis/dump ; chown sisis:sisis /home/sisis/dump COPY testdb.dmp.gz /home/sisis/dump RUN chown sisis:sisis /home/sisis/dump/testdb.dmp.gz RUN echo "/etc/init.d/postgres start" >> /usr/local/bin/start.sh RUN echo "/usr/local/bin/initSunRise.sh" >> /usr/local/bin/start.sh RUN echo "/usr/sbin/sshd -D" >> /usr/local/bin/start.sh RUN chmod 0755 /usr/local/bin/start.sh EXPOSE 22 8076 3045 ENTRYPOINT /usr/local/bin/start.sh Before it starts the SSH daemon it fires up a shellscript /usr/local/bin/initSunRise.sh which should fill the PostgreSQL server with a database. When I now start the image on the server (also a SuSE SLES) with podman run -p 2022:22 -t suse Starting PostgreSQL: ok nohup: appending output to 'nohup.out' I can SSH into the system on port 2022 and see: ssh -p 2022 root@srap57dxr1 root(a)srap57dxr1.dev.oclc.org's password: Last login: Fri Jan 12 08:35:16 2024 from 10.0.2.100 3856d0d6b62d:~ # 3856d0d6b62d:~ # ps ax PID TTY STAT TIME COMMAND 1 pts/0 Ss+ 0:00 /bin/sh -c /usr/local/bin/start.sh 30 ? S 0:00 /usr/local/sisis-pap/pgsql-15.1/bin/postmaster -D /da 33 ? Ss 0:00 postgres: logger 34 ? Ss 0:00 postgres: checkpointer 35 ? Ss 0:00 postgres: background writer 37 ? Ss 0:01 postgres: walwriter 38 ? Ss 0:00 postgres: autovacuum launcher 39 ? Ss 0:00 postgres: logical replication launcher 45 pts/0 S+ 0:00 sh -c gzip -dc /home/sisis/dump/testdb.dmp.gz | /usr/ 46 pts/0 S+ 0:00 sshd: /usr/sbin/sshd -D [listener] 0 of 10-100 startu 47 pts/0 S+ 0:09 gzip -dc /home/sisis/dump/testdb.dmp.gz 48 pts/0 S+ 0:04 /usr/local/sisis-pap/pgsql/bin/psql -Usisis sisis 49 ? Rs 1:28 postgres: sisis sisis [local] COPY 51 ? Rs 0:08 postgres: autovacuum worker sisis 52 ? Rs 0:00 sshd: root@pts/1 54 pts/1 Ss 0:00 -bash This looks all fine 47 is the process which decompresses the dump and pipes it to the proc 48 which is a SQL process loading the data into the PostgreSQL server. This looks all fine to me and works as expected. But, when I now to a 'ps ax' on the host server where the 'podman run ...' runs, I see the same proceses with other PID as they would run on the host and not in the container: 6322 pts/0 Sl+ 0:00 podman run -p 2022:22 -t suse 6337 pts/0 S 0:00 /usr/bin/slirp4netns --disable-host-loopback --mtu=65520 --enable-sandbox --enable-seccomp --enable-ipv6 -c -r 3 -e 4 --netns-type=path /data/guru/containers/tmp/netns/netns-23da4d70-34da-9034-917b-1e56362a5bbb tap0 6344 pts/0 Sl 0:00 rootlessport 6354 pts/0 Sl 0:00 rootlessport-child 6363 ? Ss 0:00 /usr/bin/conmon --api-version 1 -c 3856d0d6b62d01b46c17c160937ea6e9b8239ec64ce2c8e3ce3b4648652b47dc -u 3856d0d6b62d01b46c17c160937ea6e9b8239ec64ce2c8e3ce3b4648652b47dc -r /usr/bin/runc -b /home/apitzm/.local/share/containers/storage/overlay-containers/3856d0d6b62d01b46c17c160937ea6e9b8239ec64ce2c8e3ce3b4648652b47dc/userdata -p /home/apitzm/.local/share/containers/tmp/overlay-containers/3856d0d6b62d01b46c17c160937ea6e9b8239ec64ce2c8e3ce3b4648652b47dc/userdata/pidfile -n great_bouman --exit-dir /run/user/200007/libpod/tmp/exits --full-attach -l journald --log-level warning --syslog..... ... 6428 pts/0 S+ 0:00 sh -c gzip -dc /home/sisis/dump/testdb.dmp.gz | /usr/local/sisis-pap/pgsql/bin/psql -Usisis sisis >> /home/sisis/err 2>&1 ; /usr/local/sisis-pap/pgsql/bin/psql -Usisis sisis < ~sisis/sc/PosUpdSeq.sql >> /home/sisis/err 2>&1 6429 pts/0 S+ 0:00 sshd: /usr/sbin/sshd -D [listener] 0 of 10-100 startups 6430 pts/0 S+ 0:17 gzip -dc /home/sisis/dump/testdb.dmp.gz 6431 pts/0 S+ 0:06 /usr/local/sisis-pap/pgsql/bin/psql -Usisis sisis 6432 ? Rs 2:09 postgres: sisis sisis [local] COPY See the gzip proc 6430 and the SQL proc 6431. Is this correct so by intention that the processes which run in a container are visible from outside? Forgive me a maybe stupid question, I'm doing UNIX for 35 years and podman for 35 days :-) Thanks matthias -- Matthias Apitz, ✉ guru(a)unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub I am not at war with Russia. Я не воюю с Россией. Ich bin nicht im Krieg mit Russland.

3 2

can podman rootless support qemu-user-static for other arch?
by Larry Cai 16 Jan '24

16 Jan '24

Hi: I have a use case to run an ARM based container inside podman on an x86 platform. see https://github.com/multiarch/qemu-user-static It works for me using rootful podman env ``` [root@podman-priv /]# podman run --rm --privileged multiarch/qemu-user-static --reset -p yes[root@podman-priv /]# podman run --rm -t arm32v6/alpine uname -marmv7l[root@podman-priv /]# podman run --rm -t arm64v8/fedora uname -maarch64 ``` but when I try this in rootless environment (i am not good at technical detail in low level) ``` $ podman run --rm --privileged docker.io/multiarch/qemu-user-static --reset -p yes mount: permission denied (are you root?) mount: permission denied (are you root?) ``` so my questions: 1. is it possible to enable this for rootless env? if not, can I use sudo command to run it once 2. is it done in system level or needs to be done for each user if it is the common env Rgs, larry

2 2

Is Network=host actually insecure with rootless Podman?
by jklaiho＠iki.fi 10 Jan '24

10 Jan '24

I've run into highly mysterious and randomly occurring issues with both container-to-host and container-to-LAN PostgreSQL connections. It makes me suspect something is awry with either Podman or Pasta networking, because running the same service (a Django gunicorn process) bare metal under Supervisor using host-to-host or host-to-LAN PostgreSQL connections doesn't exhibit this issue. This post is not about that, though. To isolate what part of the system is causing the issue, I need to set up a separate test server where I'll try moving away from Pasta networking into host networking instead to verify that everything still works, and if it does, move our servers facing the connection issues to use host networking. I've read Erik Sjölund's excellent writeup at https://github.com/eriksjolund/podman-networking-docs and the Medium post it linked to claiming that host networking is insecure, at https://medium.com/nttlabs/dont-use-host-network-namespace-f548aeeef575. It deals with Docker and rootful containers, so immediately I'm thinking that the applicability to rootless Podman is limited or nonexistent. We use iptables and only expose SSH and nginx to the outside world. Any applications we run in Pasta-networked rootless containers get reverse proxied with nginx. We only run the actual applications in containers; things like PostgreSQL, nginx and Redis are all host services. Pasta has been a boon to us by conveniently exposing ports bidirectionally between container and host and preserving request IPs. The basic question is: is host networking in rootless Podman any less secure than just running the same services uncontainerized, directly on the host OS, as a non-root user? Even if we exposed a rootless containerized service port directly to the outside world without reverse proxying, I don't see how this would be any riskier with host networking than it would be with bare metal. If the risk profile is the same or very nearly the same as that, I consider that sufficient.

2 1

Podman Community Cabal meeting Tues Jan 16, 2024, 11:00 am EST (UTC-5)
by Tom Sweeney 09 Jan '24

09 Jan '24

The first Podman Community Cabal meeting of 2024 will start one week from now! We will meet on Tuesday, Jan 16, 2024, at 11:00am EST (UTC-5). Current talks on krun, crun on qemu, and image signing, and maybe more! Agenda with conference link: https://hackmd.io/gQCfskDuRLm7iOsWgH2yrg?both Hope to see you there! t

1 0

Announcement: Podman Security Fix Release: v4.8.3
by Lokesh Mandvekar 03 Jan '24

03 Jan '24

Podman v4.8.3 is now out with a security fix for CVE-2023-48795: Terrapin, a prefix truncation attack targeting the SSH protocol. CVE-2023-48795 details can be found at: [1] Mitre: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-48795 [2] GitHub Security Advisory: https://github.com/advisories/GHSA-45x7-px36-x8w8 Checkout the v4.8.3 release page for release notes and artifacts: https://github.com/containers/podman/releases/tag/v4.8.3 -- Lokesh Libera, GitLab, GitHub, Fedora: lsm5 Matrix: @lsm5:matrix.org GPG: 9E33DD8704CC03E2DEB84D9A1C1EDD7CC7C3A0DD https://keybase.io/lsm5

1 0

podman image for ngninx
by Matthias Apitz 02 Jan '24

02 Jan '24

Hello, I'm trying to build a podman image as described here: https://docs.podman.io/en/latest/Introduction.html with the command: podman build -t nginx https://git.io/Jf8ol on SuSE LINUX SLES 15 SP5. This fails with the attached nohup log. It fails mostly due to this: ... Adding system user `nginx' (UID 101) ... Adding new user `nginx' (UID 101) with group `nginx' ... Not creating home directory `/nonexistent'. + apt-get update Err:1 http://deb.debian.org/debian buster InRelease Connection failed [IP: 146.75.118.132 80] Err:2 http://deb.debian.org/debian-security buster/updates InRelease Connection failed [IP: 146.75.118.132 80] Err:3 http://deb.debian.org/debian buster-updates InRelease Connection failed [IP: 146.75.118.132 80] Reading package lists... W: Failed to fetch http://deb.debian.org/debian/dists/buster/InRelease Connection failed [IP: 146.75.118.132 80] ... What can I do? Thanks matthias -- Matthias Apitz, ✉ guru(a)unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub

3 5