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