On 1/13/24 01:47, Robin Lee Powell via Podman wrote:
This is always how containers work, yes; containers are not VMs,
they run against the same kernel as the system running them. It's a
trade off between isolation and performance.
Correct the parent PID namespace (Host PID Namespace) can see all of the
proceses runing in children PID Namespaces and can interact with them,
including killing them. Containers can not see other container
processes unless one container is a child of another container.
This is as intended and actually allows for some nice ability to
communicate between the host OS and the container through leaked unix
domain sockets and via signal passing.
On Fri, Jan 12, 2024 at 10:01:37AM +0100, Matthias Apitz wrote:
> 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.
> _______________________________________________
> 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