Thank you for the response! I actually just found the bug report for the issue it seems : https://github.com/systemd/systemd/issues/15408 The next version will include a more graceful way to handle the seccomp failures. I've overridden the systemd-logind service file inside the container by doing : $ systemctl edit systemd-logind and adding : [Service] ProtectHostname=no And that makes it work. No more errors and no degraded state.

I am surprised you need to run the systemd container with --cap-add=NET_ADMIN.

Oh actually I wanted to do some firewalling work inside the container. So no, you are right that it is not needed to get a working container. Best Regards, Philipp Richter On Tue, 28 Apr 2020 at 20:48, Daniel Walsh <dwalsh@redhat.com> wrote:

On 4/28/20 10:33, Philipp Richter wrote:

...

Hello,

I was wondering if it's normal that systemd inside a container is in a degraded state with systemd-logind not being able to start.

$ journalctl -b -a Apr 28 14:05:13 824304d0fa93 systemd[27]: systemd-logind.service: ProtectHostname=yes is configured, but UTS namespace setup is prohibited (container manager?), ignoring namespace> Apr 28 14:05:13 824304d0fa93 systemd[1]: Starting Permit User Sessions... Apr 28 14:05:13 824304d0fa93 systemd[27]: systemd-logind.service: Failed to apply hostname restrictions: Permission denied Apr 28 14:05:13 824304d0fa93 systemd[27]: systemd-logind.service: Failed at step SECCOMP spawning /usr/lib/systemd/systemd-logind: Permission denied Apr 28 14:05:13 824304d0fa93 systemd[1]: systemd-logind.service: Main process exited, code=exited, status=228/SECCOMP Apr 28 14:05:13 824304d0fa93 systemd[1]: systemd-logind.service: Failed with result 'exit-code'. Apr 28 14:05:13 824304d0fa93 systemd[1]: Failed to start Login Service. Apr 28 14:05:13 824304d0fa93 systemd[1]: systemd-logind.service: Scheduled restart job, restart counter is at 1. Apr 28 14:05:13 824304d0fa93 systemd[1]: Stopped Login Service. Apr 28 14:05:13 824304d0fa93 systemd[1]: Condition check resulted in Load Kernel Module drm being skipped. Apr 28 14:05:13 824304d0fa93 systemd[1]: Starting Login Service... Apr 28 14:05:13 824304d0fa93 systemd[31]: systemd-logind.service: ProtectHostname=yes is configured, but UTS namespace setup is prohibited (container manager?), ignoring namespace> Apr 28 14:05:13 824304d0fa93 systemd[31]: systemd-logind.service: Failed to apply hostname restrictions: Permission denied Apr 28 14:05:13 824304d0fa93 systemd[31]: systemd-logind.service: Failed at step SECCOMP spawning /usr/lib/systemd/systemd-logind: Permission denied Apr 28 14:05:13 824304d0fa93 systemd[1]: systemd-logind.service: Main process exited, code=exited, status=228/SECCOMP Apr 28 14:05:13 824304d0fa93 systemd[1]: systemd-logind.service: Failed with result 'exit-code'. Apr 28 14:05:13 824304d0fa93 systemd[1]: Failed to start Login Service.

Then $ systemctl status gives :

● 824304d0fa93 State: degraded Jobs: 0 queued Failed: 1 units Since: Tue 2020-04-28 14:05:11 UTC; 23min ago CGroup: / ├─crun-exec │ ├─43 bash │ ├─70 systemctl status │ └─71 less ├─init.scope │ └─1 /sbin/init └─system.slice ├─systemd-journald.service │ └─15 /usr/lib/systemd/systemd-journald └─dbus.service └─26 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation --syslog-only

I am starting a custom archlinux base image like this :

$ sudo podman run -d --cap-add=NET_ADMIN localhost/popsulfr/archlinux-base /sbin/init

The output of podman info :

host: arch: arm64 buildahVersion: 1.14.8 cgroupVersion: v2 conmon: package: Unknown path: /usr/bin/conmon version: 'conmon version 2.0.15, commit: 1bddbf7051a973f4a4fecf06faa0c48e82f1e9e1' cpus: 4 distribution: distribution: archarm version: unknown eventLogger: journald hostname: rock64 idMappings: gidmap: null uidmap: null kernel: 5.6.7-1-ARCH memFree: 3530731520 memTotal: 4097687552 ociRuntime: name: crun package: Unknown path: /usr/bin/crun version: |- crun version 0.13 commit: e79e4de4ac16da0ce48777afb72c6241de870525 spec: 1.0.0 +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +YAJL os: linux rootless: false slirp4netns: executable: "" package: "" version: "" swapFree: 0 swapTotal: 0 uptime: 29m 39.39s registries: search: - docker.io - registry.fedoraproject.org - quay.io - registry.access.redhat.com - registry.centos.org store: configFile: /etc/containers/storage.conf containerStore: number: 1 paused: 0 running: 1 stopped: 0 graphDriverName: overlay graphOptions: overlay.mountopt: nodev graphRoot: /var/lib/containers/storage graphStatus: Backing Filesystem: btrfs Native Overlay Diff: "true" Supports d_type: "true" Using metacopy: "false" imageStore: number: 1 runRoot: /var/run/containers/storage volumePath: /var/lib/containers/storage/volumes

Best Regards, Philipp Richter _______________________________________________ Podman mailing list -- podman@lists.podman.io To unsubscribe send an email to podman-leave@lists.podman.io

I think it depends on the way the systemd inside of the container is setup to run.

I am surprised you need to run the systemd container with --cap-add NET_ADMIN.

I would figure this is not necessary unless you want systemd inside of the container to modify the host kernels network?

There are going to be some functions that systemd will be blocked, but you can loosen the security if you want these to function. Systemd is smart enough to figure out that it is running in a container and will modify the way it runs based on this. For example it will see that it does not have CAP_SYS_ADMIN and will not attempt to

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