Your message dated Tue, 16 Jan 2024 11:07:56 +0100
with message-id <[email protected]>
and subject line Re: [pkg-apparmor] Bug#1050256: autopkgtest fails on debci
has caused the Debian Bug report #1042880,
regarding systemd: service with PrivateNetwork=yes fails inside lxc container
on bookworm
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
1042880: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1042880
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: systemd
Version: 254-1
Severity: normal
X-Debbugs-Cc: [email protected]
The PrivateNetwork=yes option hardens services by putting them in a private
network namespace.
systemd.exec(5) says:
> Note that the implementation of this setting might be impossible (for
> example if network namespaces are not available), and the unit should be
> written in a way that does not solely rely on this setting for security.
which makes me think that the intended behaviour of this option is: if
possible, put the service in a private network namespace, but if that's
not possible, then launch it anyway.
However, in a lxc container, this isn't working for me, causing
autopkgtest failure for policykit-1 (>= 123) (which I'm going to work
around by removing the PrivateNetwork=yes option for now). This is
important because ci.debian.net can currently only test packages in an
lxc container.
Steps to reproduce
==================
On a Debian 12 'bookworm' system (I used a throwaway VM created by
autopkgtest-build-qemu to get a somewhat reproducible environment):
# apt install ca-certificates debootstrap libpam-cgfs lxcfs lxc-templates \
rsync uidmap autopkgtest
# autopkgtest-build-lxc debian trixie amd64
# lxc-start autopkgtest-trixie-amd64
# lxc-attach autopkgtest-trixie-amd64
root@autopkgtest-trixie-amd64:~# cat > /lib/systemd/system/test.service <<EOF
[Unit]
Description=A test
[Service]
Type=oneshot
ExecStart=/bin/true
PrivateNetwork=yes
EOF
root@autopkgtest-trixie-amd64:~# systemctl daemon-reload
root@autopkgtest-trixie-amd64:~# systemctl start test.service
root@autopkgtest-trixie-amd64:~# systemctl status test.service
root@autopkgtest-trixie-amd64:~# poweroff
Expected result
===============
Successful start
Actual result
=============
root@autopkgtest-trixie-amd64:~# systemctl start test.service
Job for test.service failed because the control process exited with error code.
See "systemctl status test.service" and "journalctl -xeu test.service" for
details.
root@autopkgtest-trixie-amd64:~# systemctl status test.service
× test.service - A test
Loaded: loaded (/lib/systemd/system/test.service; static)
Active: failed (Result: exit-code) since Wed 2023-08-02 10:24:00 UTC; 15s
ago
Process: 146 ExecStart=/bin/true (code=exited, status=225/NETWORK)
Main PID: 146 (code=exited, status=225/NETWORK)
CPU: 8ms
Aug 02 10:24:00 autopkgtest-trixie-amd64 systemd[1]: Starting test.service - A
test...
Aug 02 10:24:00 autopkgtest-trixie-amd64 (true)[146]: test.service: Failed to
set up network namespacing: Resource temporarily unavailable
Aug 02 10:24:00 autopkgtest-trixie-amd64 (true)[146]: test.service: Failed at
step NETWORK spawning /bin/true: Resource temporarily unavailable
Aug 02 10:24:00 autopkgtest-trixie-amd64 systemd[1]: test.service: Main process
exited, code=exited, status=225/NETWORK
Aug 02 10:24:00 autopkgtest-trixie-amd64 systemd[1]: test.service: Failed with
result 'exit-code'.
Aug 02 10:24:00 autopkgtest-trixie-amd64 systemd[1]: Failed to start
test.service - A test.
Workaround
==========
Remove PrivateNetwork=yes from unit files that are expected to work or
be tested in an lxc container.
-- System Information:
Debian Release: trixie/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 6.1.0-9-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=en_GB.utf8, LC_CTYPE=C.UTF-8 (charmap=locale: Cannot set
LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages systemd depends on:
ii libacl1 2.3.1-3
ii libaudit1 1:3.1.1-1
ii libblkid1 2.39.1-3
ii libc6 2.37-6
ii libcap2 1:2.66-4
ii libcryptsetup12 2:2.6.1-4
ii libfdisk1 2.39.1-3
ii libgcrypt20 1.10.2-2
ii libkmod2 30+20230519-1
ii liblz4-1 1.9.4-1
ii liblzma5 5.4.1-0.2
ii libmount1 2.39.1-3
ii libp11-kit0 0.25.0-3
ii libseccomp2 2.5.4-1+b3
ii libselinux1 3.5-1
ii libssl3 3.0.9-1
ii libsystemd-shared 254-1
ii libsystemd0 254-1
ii libzstd1 1.5.5+dfsg2-1
ii mount 2.39.1-3
ii systemd-dev 254-1
Versions of packages systemd recommends:
ii dbus [default-dbus-system-bus] 1.14.8-2
pn systemd-timesyncd | time-daemon <none>
Versions of packages systemd suggests:
ii libfido2-1 1.13.0-1
pn libqrencode4 <none>
pn libtss2-esys-3.0.2-0 <none>
pn libtss2-mu0 <none>
pn libtss2-rc0 <none>
pn polkitd <none>
ii python3 3.11.4-5
pn python3-pefile <none>
pn systemd-boot <none>
pn systemd-container <none>
pn systemd-homed <none>
pn systemd-resolved <none>
pn systemd-userdbd <none>
Versions of packages systemd is related to:
ii dbus-user-session 1.14.8-2
pn dracut <none>
pn initramfs-tools <none>
pn libnss-systemd <none>
ii libpam-systemd 254-1
pn udev <none>
-- debconf information:
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = (unset),
LC_ALL = (unset),
LC_CTYPE = "C.UTF-8",
LANG = "en_GB.utf8"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
--- End Message ---
--- Begin Message ---
On Sun, 17 Sep 2023 12:12:17 +0530 intrigeri <[email protected]> wrote:
Dear lxd and systemd maintainers,
Michael Biebl (2023-09-11):
> When you do the reassignment, you should probably merge this bug report
> with #1038315 and #1042880, now that we know what the root cause is.
FTR I did not dare merging these myself: perhaps you want to keep
separate bug reports to track workarounds on top of #1050256 that's
tracking the root cause, or something.
I don't think it we are going to apply any workarounds for this in
systemd but hope that the root cause in the kernel (as tracked in
#1050256) is fixed eventually.
Closing the bug report accordingly.
Regards,
Michael
OpenPGP_signature.asc
Description: OpenPGP digital signature
--- End Message ---
