[Touch-packages] [Bug 1959047] Re: systemd ignores RootDirectory option in .service units
This bug was fixed in the package systemd - 255.2-3ubuntu2 --- systemd (255.2-3ubuntu2) noble; urgency=medium * test: skip test_exec_networknamespacepath if netns setup fails (LP: #2046498) Files: - debian/patches/lp2046498-test-skip-test_exec_networknamespacepath-if-netns-setup-f.patch - debian/patches/test-skip-failing-test-execute-tests-in-LXC.patch https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=de1fcf756e47858f4a206db97434bce4a71384d0 * test: skip TEST-43-PRIVATEUSER-UNPRIV if unprivileged userns is restricted File: debian/patches/test-skip-TEST-43-PRIVATEUSER-UNPRIV-if-unprivileged-user.patch https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=2aba69874c83289c43d199ca360aa2fc451486a7 * Drop debian/UBUNTU-src-test-test-execute.c-Skip-parts-of-test-execute-in-con.patch. This will be re-addressed with a different patch. File: debian/patches/debian/UBUNTU-src-test-test-execute.c-Skip-parts-of-test-execute-in-con.patch https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=c3cd814e028364fe0c641d4bacfce22aafd1b572 * Drop test-skip-failing-test-execute-tests-in-LXC.patch. This will be re-addressed with different patches. File: debian/patches/test-skip-failing-test-execute-tests-in-LXC.patch https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=ab853707f4cc3e7e2d5993ff38998c3c2c789f62 * test: temporarily skip credentials tests in LXC. This was already skipped in another patch, but now that we know what's going on with it, split it out. File: debian/patches/test-temporarily-skip-credentials-tests-in-LXC.patch https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=c71acb411d315267fe811f024cdab97e032453f3 * test: skip test-execute in arhmf LXC containers File: debian/patches/test-skip-test-execute-in-arhmf-LXC-containers.patch https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=1cb1e3060822bfadddead564e779942e73e02f62 * test: skip exec-privatenetwork-yes-privatemounts-yes.service in LXC (LP: #2046495) File: debian/patches/test-skip-exec-privatenetwork-yes-privatemounts-yes.servi.patch https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=3ab76fd2db4291ee0531a07085c72cee06cb0d12 * test: skip a systemd-run test if unprivileged userns is restricted File: debian/patches/test-skip-a-systemd-run-test-if-unprivileged-userns-is-re.patch https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=c85f2b4e32ee8fd1c0dc58d23e7fabdb7590d3cc * test-execute: skip tests that are broken without unprivileged userns File: debian/patches/test-execute-skip-tests-that-are-broken-without-unprivile.patch https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=7a6573c4f5133a7fec11fb059dd215f7c8c2204e -- Nick Rosbrook Wed, 24 Jan 2024 14:53:46 -0500 ** Changed in: systemd (Ubuntu) Status: Confirmed => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1959047 Title: systemd ignores RootDirectory option in .service units Status in lxd package in Ubuntu: Invalid Status in systemd package in Ubuntu: Fix Released Status in lxd source package in Bionic: Fix Released Status in systemd source package in Bionic: Confirmed Status in systemd source package in Focal: Confirmed Status in systemd source package in Impish: Confirmed Bug description: [Impact] Ubuntu carries a patch on top of systemd [a] to silence namespace set up failures. This is meant as a workaround for a bug in the LXD version shipped in Ubuntu 18.04. Masking namespace set up failures creates a false sense of security for the user/admin. As mentioned in comment #1, systemd upstream explains that silencing this kind of error is dangerous and should be avoided. Backporting the LXD fix [b] to Ubuntu 18.04 would allow namespaces to work inside containers. This is the goal of this SRU. Ultimately, once LXD in Ubuntu 18.04 includes the fix [b], it would be possible to drop the Ubuntu-specific patch for systemd [a]. This is however *not an immediate concern for this SRU*. [Test Plan] 1) Create a 18.04 VM: $ lxc launch images:ubuntu/18.04 lp1959047 --vm $ sleep 30 # give it time to boot 1.5) Enable bionic-proposed: $ echo "deb http://archive.ubuntu.com/ubuntu bionic-proposed main restricted universe multiverse" | lxc file push - lp1959047/etc/apt/sources.list.d/proposed.list 2) Install and initialize LXD in it: $ lxc exec lp1959047 -- apt-get update $ lxc exec lp1959047 -- apt-get install -y lxd $ lxc exec lp1959047 -- lxd init --auto 3) Create a Jammy container and enable systemd debugging: $ lxc exec lp1959047 -- lxc
[Touch-packages] [Bug 1959047] Re: systemd ignores RootDirectory option in .service units
Can we change bug importance to fix systemd in Jammy? Most of my services run chroot'ed within LXD, I can't use Jammy. :( -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1959047 Title: systemd ignores RootDirectory option in .service units Status in lxd package in Ubuntu: Invalid Status in systemd package in Ubuntu: Confirmed Status in lxd source package in Bionic: Fix Released Status in systemd source package in Bionic: Confirmed Status in systemd source package in Focal: Confirmed Status in systemd source package in Impish: Confirmed Bug description: [Impact] Ubuntu carries a patch on top of systemd [a] to silence namespace set up failures. This is meant as a workaround for a bug in the LXD version shipped in Ubuntu 18.04. Masking namespace set up failures creates a false sense of security for the user/admin. As mentioned in comment #1, systemd upstream explains that silencing this kind of error is dangerous and should be avoided. Backporting the LXD fix [b] to Ubuntu 18.04 would allow namespaces to work inside containers. This is the goal of this SRU. Ultimately, once LXD in Ubuntu 18.04 includes the fix [b], it would be possible to drop the Ubuntu-specific patch for systemd [a]. This is however *not an immediate concern for this SRU*. [Test Plan] 1) Create a 18.04 VM: $ lxc launch images:ubuntu/18.04 lp1959047 --vm $ sleep 30 # give it time to boot 1.5) Enable bionic-proposed: $ echo "deb http://archive.ubuntu.com/ubuntu bionic-proposed main restricted universe multiverse" | lxc file push - lp1959047/etc/apt/sources.list.d/proposed.list 2) Install and initialize LXD in it: $ lxc exec lp1959047 -- apt-get update $ lxc exec lp1959047 -- apt-get install -y lxd $ lxc exec lp1959047 -- lxd init --auto 3) Create a Jammy container and enable systemd debugging: $ lxc exec lp1959047 -- lxc init images:ubuntu/22.04 c1 $ lxc exec lp1959047 -- lxc config set c1 raw.lxc 'lxc.init.cmd = /sbin/init systemd.log_level=debug' $ lxc exec lp1959047 -- lxc start c1 4) Check if namespace set up failures are logged: $ lxc exec lp1959047 -- lxc exec c1 -- journalctl -b0 --grep 'Failed to set up namespace' Mar 24 23:29:19 c1 systemd[99]: systemd-udevd.service: Failed to set up namespace, assuming containerized execution, ignoring: Permission denied Mar 24 23:29:19 c1 systemd[132]: systemd-networkd.service: Failed to set up namespace, assuming containerized execution, ignoring: Permission denied Mar 24 23:29:19 c1 systemd[131]: systemd-logind.service: Failed to set up namespace, assuming containerized execution, ignoring: Permission denied Mar 24 23:29:20 c1 systemd[136]: systemd-resolved.service: Failed to set up namespace, assuming containerized execution, ignoring: Permission denied Mar 24 23:29:20 c1 systemd[128]: e2scrub_reap.service: Failed to set up namespace, assuming containerized execution, ignoring: Permission denied Mar 24 23:29:23 c1 systemd[243]: systemd-hostnamed.service: Failed to set up namespace, assuming containerized execution, ignoring: Permission denied If LXD in Ubuntu 18.04 has the patch, the "Failed to set up namespace" messages wouldn't be there. [Where problems could occur] The LXD fix changes the Apparmor profile used for containers. This essentially loosen the mount restrictions applied to containers. Weakening the Apparmor profile could make it easier for a process in the container to do damage that would have otherwise been blocked. On the other hand, this allows making use of namespaces/sandboxing inside the container. Upstream LXD has the fix since 2019 which make it less likely to run into problems with the backport. The backported fix was also tested manually to ensure LXD still behaved normally and that it avoided the namespace set up failures in Jammy containers. [a]: https://git.launchpad.net/ubuntu/+source/systemd/tree/debian/patches/debian/UBUNTU-Revert-namespace-be-more-careful-when-handling-namespacin.patch?h=ubuntu/jammy [b]: https://github.com/lxc/lxd/commit/a6b780703350faff8328f3d565f6bac7b6dcf59f [Initial bug description] The version of systemd (249.5-2ubuntu4) currently packaged for the Ubuntu development version (22.04 Jammy Jellyfish) totally ignores the RootDirectory= option in systemd service files. With RootDirectory, systemd should start the service after calling chroot() on the supplied directory. To test/reproduce, create a test service file with the following contents: # /etc/systemd/system/lsb-release.service [Unit] Description=LSB Release Information [Service] Type=simple RootDirectory=/var/chroot/trusty ExecStartPre=/bin/pwd ExecStart=/usr/bin/lsb_release -a You should have a chroot environment in the specified RootDirectory, even though you can still deduce
[Touch-packages] [Bug 1959047] Re: systemd ignores RootDirectory option in .service units
This bug was fixed in the package lxd - 3.0.3-0ubuntu1~18.04.2 --- lxd (3.0.3-0ubuntu1~18.04.2) bionic; urgency=medium * Cherry-pick upstream bugfixes: - 0001-lxd-apparmor-Tweak-default-set-of-rules.patch (LP: #1959047) -- Stéphane Graber Thu, 24 Mar 2022 12:18:01 -0400 ** Changed in: lxd (Ubuntu Bionic) Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1959047 Title: systemd ignores RootDirectory option in .service units Status in lxd package in Ubuntu: Invalid Status in systemd package in Ubuntu: Confirmed Status in lxd source package in Bionic: Fix Released Status in systemd source package in Bionic: Confirmed Status in systemd source package in Focal: Confirmed Status in systemd source package in Impish: Confirmed Bug description: [Impact] Ubuntu carries a patch on top of systemd [a] to silence namespace set up failures. This is meant as a workaround for a bug in the LXD version shipped in Ubuntu 18.04. Masking namespace set up failures creates a false sense of security for the user/admin. As mentioned in comment #1, systemd upstream explains that silencing this kind of error is dangerous and should be avoided. Backporting the LXD fix [b] to Ubuntu 18.04 would allow namespaces to work inside containers. This is the goal of this SRU. Ultimately, once LXD in Ubuntu 18.04 includes the fix [b], it would be possible to drop the Ubuntu-specific patch for systemd [a]. This is however *not an immediate concern for this SRU*. [Test Plan] 1) Create a 18.04 VM: $ lxc launch images:ubuntu/18.04 lp1959047 --vm $ sleep 30 # give it time to boot 1.5) Enable bionic-proposed: $ echo "deb http://archive.ubuntu.com/ubuntu bionic-proposed main restricted universe multiverse" | lxc file push - lp1959047/etc/apt/sources.list.d/proposed.list 2) Install and initialize LXD in it: $ lxc exec lp1959047 -- apt-get update $ lxc exec lp1959047 -- apt-get install -y lxd $ lxc exec lp1959047 -- lxd init --auto 3) Create a Jammy container and enable systemd debugging: $ lxc exec lp1959047 -- lxc init images:ubuntu/22.04 c1 $ lxc exec lp1959047 -- lxc config set c1 raw.lxc 'lxc.init.cmd = /sbin/init systemd.log_level=debug' $ lxc exec lp1959047 -- lxc start c1 4) Check if namespace set up failures are logged: $ lxc exec lp1959047 -- lxc exec c1 -- journalctl -b0 --grep 'Failed to set up namespace' Mar 24 23:29:19 c1 systemd[99]: systemd-udevd.service: Failed to set up namespace, assuming containerized execution, ignoring: Permission denied Mar 24 23:29:19 c1 systemd[132]: systemd-networkd.service: Failed to set up namespace, assuming containerized execution, ignoring: Permission denied Mar 24 23:29:19 c1 systemd[131]: systemd-logind.service: Failed to set up namespace, assuming containerized execution, ignoring: Permission denied Mar 24 23:29:20 c1 systemd[136]: systemd-resolved.service: Failed to set up namespace, assuming containerized execution, ignoring: Permission denied Mar 24 23:29:20 c1 systemd[128]: e2scrub_reap.service: Failed to set up namespace, assuming containerized execution, ignoring: Permission denied Mar 24 23:29:23 c1 systemd[243]: systemd-hostnamed.service: Failed to set up namespace, assuming containerized execution, ignoring: Permission denied If LXD in Ubuntu 18.04 has the patch, the "Failed to set up namespace" messages wouldn't be there. [Where problems could occur] The LXD fix changes the Apparmor profile used for containers. This essentially loosen the mount restrictions applied to containers. Weakening the Apparmor profile could make it easier for a process in the container to do damage that would have otherwise been blocked. On the other hand, this allows making use of namespaces/sandboxing inside the container. Upstream LXD has the fix since 2019 which make it less likely to run into problems with the backport. The backported fix was also tested manually to ensure LXD still behaved normally and that it avoided the namespace set up failures in Jammy containers. [a]: https://git.launchpad.net/ubuntu/+source/systemd/tree/debian/patches/debian/UBUNTU-Revert-namespace-be-more-careful-when-handling-namespacin.patch?h=ubuntu/jammy [b]: https://github.com/lxc/lxd/commit/a6b780703350faff8328f3d565f6bac7b6dcf59f [Initial bug description] The version of systemd (249.5-2ubuntu4) currently packaged for the Ubuntu development version (22.04 Jammy Jellyfish) totally ignores the RootDirectory= option in systemd service files. With RootDirectory, systemd should start the service after calling chroot() on the supplied directory. To test/reproduce, create a test service file with the following contents: # /etc/systemd/system/lsb-release.service [Unit]
[Touch-packages] [Bug 1959047] Re: systemd ignores RootDirectory option in .service units
Bionic verification was successfully done using the steps outlined in the bug description. The important parts are captured here: $ lxc exec lp1959047 -- apt-get install -y lxd Reading package lists... Done Building dependency tree Reading state information... Done The following additional packages will be installed: acl apparmor dns-root-data dnsmasq-base ebtables iptables libip6tc0 libiptc0 liblxc-common liblxc1 liblzo2-2 libnetfilter-conntrack3 libnfnetlink0 libuv1 lxcfs lxd-client rsync squashfs-tools uidmap xdelta3 Suggested packages: apparmor-profiles-extra apparmor-utils criu lxd-tools openssh-server The following NEW packages will be installed: acl apparmor dns-root-data dnsmasq-base ebtables iptables libip6tc0 libiptc0 liblxc-common liblxc1 liblzo2-2 libnetfilter-conntrack3 libnfnetlink0 libuv1 lxcfs lxd lxd-client rsync squashfs-tools uidmap xdelta3 0 upgraded, 21 newly installed, 0 to remove and 9 not upgraded. Need to get 10.9 MB of archives. After this operation, 41.3 MB of additional disk space will be used. Get:1 http://archive.ubuntu.com/ubuntu bionic/main amd64 libnfnetlink0 amd64 1.0.1-3 [13.3 kB] Get:2 http://archive.ubuntu.com/ubuntu bionic/main amd64 liblzo2-2 amd64 2.08-1.2 [48.7 kB] Get:3 http://archive.ubuntu.com/ubuntu bionic-updates/main amd64 apparmor amd64 2.12-4ubuntu5.1 [487 kB] Get:4 http://archive.ubuntu.com/ubuntu bionic/main amd64 libip6tc0 amd64 1.6.1-2ubuntu2 [19.9 kB] Get:5 http://archive.ubuntu.com/ubuntu bionic/main amd64 libiptc0 amd64 1.6.1-2ubuntu2 [9308 B] Get:6 http://archive.ubuntu.com/ubuntu bionic/main amd64 libnetfilter-conntrack3 amd64 1.0.6-2 [37.8 kB] Get:7 http://archive.ubuntu.com/ubuntu bionic/main amd64 iptables amd64 1.6.1-2ubuntu2 [269 kB] Get:8 http://archive.ubuntu.com/ubuntu bionic-updates/main amd64 rsync amd64 3.1.2-2.1ubuntu1.3 [335 kB] Get:9 http://archive.ubuntu.com/ubuntu bionic/main amd64 acl amd64 2.2.52-3build1 [38.5 kB] Get:10 http://archive.ubuntu.com/ubuntu bionic/main amd64 dns-root-data all 2018013001 [5360 B] Get:11 http://archive.ubuntu.com/ubuntu bionic-updates/main amd64 dnsmasq-base amd64 2.79-1ubuntu0.5 [307 kB] Get:12 http://archive.ubuntu.com/ubuntu bionic-updates/main amd64 ebtables amd64 2.0.10.4-3.5ubuntu2.18.04.3 [79.9 kB] Get:13 http://archive.ubuntu.com/ubuntu bionic-updates/main amd64 liblxc1 amd64 3.0.3-0ubuntu1~18.04.1 [264 kB] Get:14 http://archive.ubuntu.com/ubuntu bionic-updates/main amd64 liblxc-common amd64 3.0.3-0ubuntu1~18.04.1 [438 kB] Get:15 http://archive.ubuntu.com/ubuntu bionic/main amd64 libuv1 amd64 1.18.0-3 [64.4 kB] Get:16 http://archive.ubuntu.com/ubuntu bionic-updates/main amd64 lxcfs amd64 3.0.3-0ubuntu1~18.04.2 [39.0 kB] Get:17 http://archive.ubuntu.com/ubuntu bionic-proposed/main amd64 lxd-client amd64 3.0.3-0ubuntu1~18.04.2 [3025 kB] Get:18 http://archive.ubuntu.com/ubuntu bionic-updates/main amd64 squashfs-tools amd64 1:4.3-6ubuntu0.18.04.4 [111 kB] Get:19 http://archive.ubuntu.com/ubuntu bionic-proposed/main amd64 uidmap amd64 1:4.5-1ubuntu2.3 [68.0 kB] Get:20 http://archive.ubuntu.com/ubuntu bionic/main amd64 xdelta3 amd64 3.0.11-dfsg-1ubuntu1 [68.9 kB] Get:21 http://archive.ubuntu.com/ubuntu bionic-proposed/main amd64 lxd amd64 3.0.3-0ubuntu1~18.04.2 [5199 kB] Fetched 10.9 MB in 4s (2980 kB/s) ... Unpacking xdelta3 (3.0.11-dfsg-1ubuntu1) ... Selecting previously unselected package lxd. Preparing to unpack .../20-lxd_3.0.3-0ubuntu1~18.04.2_amd64.deb ... Adding system user `lxd' (UID 105) ... Adding new user `lxd' (UID 105) with group `nogroup' ... Creating home directory `/var/lib/lxd/' ... Adding group `lxd' (GID 109) ... Done. Unpacking lxd (3.0.3-0ubuntu1~18.04.2) ... ... Setting up liblxc1 (3.0.3-0ubuntu1~18.04.1) ... Setting up liblxc-common (3.0.3-0ubuntu1~18.04.1) ... apparmor.service is not active, cannot reload. invoke-rc.d: initscript apparmor, action "reload" failed. Setting up lxd (3.0.3-0ubuntu1~18.04.2) ... ... $ lxc exec lp1959047 -- lxc exec c1 -- journalctl -b0 --grep 'Failed to set up namespace' -- No entries -- So it worked, thanks! ** Tags removed: verification-needed verification-needed-bionic ** Tags added: verification-done verification-done-bionic -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1959047 Title: systemd ignores RootDirectory option in .service units Status in lxd package in Ubuntu: Invalid Status in systemd package in Ubuntu: Confirmed Status in lxd source package in Bionic: Fix Committed Status in systemd source package in Bionic: Confirmed Status in systemd source package in Focal: Confirmed Status in systemd source package in Impish: Confirmed Bug description: [Impact] Ubuntu carries a patch on top of systemd [a] to silence namespace set up failures. This is meant as a workaround for a bug in the LXD version shipped in Ubuntu 18.04. Masking namespace set up
[Touch-packages] [Bug 1959047] Re: systemd ignores RootDirectory option in .service units
** Description changed: [Impact] Ubuntu carries a patch on top of systemd [a] to silence namespace set up failures. This is meant as a workaround for a bug in the LXD version shipped in Ubuntu 18.04. Masking namespace set up failures creates a false sense of security for the user/admin. As mentioned in comment #1, systemd upstream explains that silencing this kind of error is dangerous and should be avoided. Backporting the LXD fix [b] to Ubuntu 18.04 would allow namespaces to work inside containers. This is the goal of this SRU. Ultimately, once LXD in Ubuntu 18.04 includes the fix [b], it would be possible to drop the Ubuntu-specific patch for systemd [a]. This is however *not an immediate concern for this SRU*. [Test Plan] 1) Create a 18.04 VM: $ lxc launch images:ubuntu/18.04 lp1959047 --vm $ sleep 30 # give it time to boot + + 1.5) Enable bionic-proposed: + $ echo "deb http://archive.ubuntu.com/ubuntu bionic-proposed main restricted universe multiverse" | lxc file push - lp1959047/etc/apt/sources.list.d/proposed.list 2) Install and initialize LXD in it: $ lxc exec lp1959047 -- apt-get update $ lxc exec lp1959047 -- apt-get install -y lxd $ lxc exec lp1959047 -- lxd init --auto 3) Create a Jammy container and enable systemd debugging: $ lxc exec lp1959047 -- lxc init images:ubuntu/22.04 c1 $ lxc exec lp1959047 -- lxc config set c1 raw.lxc 'lxc.init.cmd = /sbin/init systemd.log_level=debug' $ lxc exec lp1959047 -- lxc start c1 4) Check if namespace set up failures are logged: $ lxc exec lp1959047 -- lxc exec c1 -- journalctl -b0 --grep 'Failed to set up namespace' Mar 24 23:29:19 c1 systemd[99]: systemd-udevd.service: Failed to set up namespace, assuming containerized execution, ignoring: Permission denied Mar 24 23:29:19 c1 systemd[132]: systemd-networkd.service: Failed to set up namespace, assuming containerized execution, ignoring: Permission denied Mar 24 23:29:19 c1 systemd[131]: systemd-logind.service: Failed to set up namespace, assuming containerized execution, ignoring: Permission denied Mar 24 23:29:20 c1 systemd[136]: systemd-resolved.service: Failed to set up namespace, assuming containerized execution, ignoring: Permission denied Mar 24 23:29:20 c1 systemd[128]: e2scrub_reap.service: Failed to set up namespace, assuming containerized execution, ignoring: Permission denied Mar 24 23:29:23 c1 systemd[243]: systemd-hostnamed.service: Failed to set up namespace, assuming containerized execution, ignoring: Permission denied If LXD in Ubuntu 18.04 has the patch, the "Failed to set up namespace" messages wouldn't be there. [Where problems could occur] The LXD fix changes the Apparmor profile used for containers. This essentially loosen the mount restrictions applied to containers. Weakening the Apparmor profile could make it easier for a process in the container to do damage that would have otherwise been blocked. On the other hand, this allows making use of namespaces/sandboxing inside the container. Upstream LXD has the fix since 2019 which make it less likely to run into problems with the backport. The backported fix was also tested manually to ensure LXD still behaved normally and that it avoided the namespace set up failures in Jammy containers. [a]: https://git.launchpad.net/ubuntu/+source/systemd/tree/debian/patches/debian/UBUNTU-Revert-namespace-be-more-careful-when-handling-namespacin.patch?h=ubuntu/jammy [b]: https://github.com/lxc/lxd/commit/a6b780703350faff8328f3d565f6bac7b6dcf59f [Initial bug description] The version of systemd (249.5-2ubuntu4) currently packaged for the Ubuntu development version (22.04 Jammy Jellyfish) totally ignores the RootDirectory= option in systemd service files. With RootDirectory, systemd should start the service after calling chroot() on the supplied directory. To test/reproduce, create a test service file with the following contents: # /etc/systemd/system/lsb-release.service [Unit] Description=LSB Release Information [Service] Type=simple RootDirectory=/var/chroot/trusty ExecStartPre=/bin/pwd ExecStart=/usr/bin/lsb_release -a You should have a chroot environment in the specified RootDirectory, even though you can still deduce if systemd attempted to chroot or not from the resulting error message. In my example, I installed an end-of-life Ubuntu 14.04 Trusty Tahr in the chroot environment. On systems NOT affected by the problem, I get the following result when I start this test service. This is what I'd expect. Jan 25 20:40:40 dolly systemd[1]: Starting LSB Release Information... Jan 25 20:40:40 dolly pwd[361]: / Jan 25 20:40:40 dolly systemd[1]: Started LSB Release Information. Jan 25 20:40:40 dolly lsb_release[362]: No LSB modules are available. Jan 25 20:40:40 dolly lsb_release[362]: Distributor ID:Ubuntu
[Touch-packages] [Bug 1959047] Re: systemd ignores RootDirectory option in .service units
Hello MegaBrutal, or anyone else affected, Accepted lxd into bionic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/lxd/3.0.3-0ubuntu1~18.04.2 in a few hours, and then in the -proposed repository. Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users. If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed- bionic to verification-done-bionic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification- failed-bionic. In either case, without details of your testing we will not be able to proceed. Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping! N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days. ** Changed in: lxd (Ubuntu Bionic) Status: In Progress => Fix Committed ** Tags added: verification-needed verification-needed-bionic -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1959047 Title: systemd ignores RootDirectory option in .service units Status in lxd package in Ubuntu: Invalid Status in systemd package in Ubuntu: Confirmed Status in lxd source package in Bionic: Fix Committed Status in systemd source package in Bionic: Confirmed Status in systemd source package in Focal: Confirmed Status in systemd source package in Impish: Confirmed Bug description: [Impact] Ubuntu carries a patch on top of systemd [a] to silence namespace set up failures. This is meant as a workaround for a bug in the LXD version shipped in Ubuntu 18.04. Masking namespace set up failures creates a false sense of security for the user/admin. As mentioned in comment #1, systemd upstream explains that silencing this kind of error is dangerous and should be avoided. Backporting the LXD fix [b] to Ubuntu 18.04 would allow namespaces to work inside containers. This is the goal of this SRU. Ultimately, once LXD in Ubuntu 18.04 includes the fix [b], it would be possible to drop the Ubuntu-specific patch for systemd [a]. This is however *not an immediate concern for this SRU*. [Test Plan] 1) Create a 18.04 VM: $ lxc launch images:ubuntu/18.04 lp1959047 --vm $ sleep 30 # give it time to boot 2) Install and initialize LXD in it: $ lxc exec lp1959047 -- apt-get update $ lxc exec lp1959047 -- apt-get install -y lxd $ lxc exec lp1959047 -- lxd init --auto 3) Create a Jammy container and enable systemd debugging: $ lxc exec lp1959047 -- lxc init images:ubuntu/22.04 c1 $ lxc exec lp1959047 -- lxc config set c1 raw.lxc 'lxc.init.cmd = /sbin/init systemd.log_level=debug' $ lxc exec lp1959047 -- lxc start c1 4) Check if namespace set up failures are logged: $ lxc exec lp1959047 -- lxc exec c1 -- journalctl -b0 --grep 'Failed to set up namespace' Mar 24 23:29:19 c1 systemd[99]: systemd-udevd.service: Failed to set up namespace, assuming containerized execution, ignoring: Permission denied Mar 24 23:29:19 c1 systemd[132]: systemd-networkd.service: Failed to set up namespace, assuming containerized execution, ignoring: Permission denied Mar 24 23:29:19 c1 systemd[131]: systemd-logind.service: Failed to set up namespace, assuming containerized execution, ignoring: Permission denied Mar 24 23:29:20 c1 systemd[136]: systemd-resolved.service: Failed to set up namespace, assuming containerized execution, ignoring: Permission denied Mar 24 23:29:20 c1 systemd[128]: e2scrub_reap.service: Failed to set up namespace, assuming containerized execution, ignoring: Permission denied Mar 24 23:29:23 c1 systemd[243]: systemd-hostnamed.service: Failed to set up namespace, assuming containerized execution, ignoring: Permission denied If LXD in Ubuntu 18.04 has the patch, the "Failed to set up namespace" messages wouldn't be there. [Where problems could occur] The LXD fix changes the Apparmor profile used for containers. This essentially loosen the mount restrictions applied to containers. Weakening the Apparmor profile could make it easier for a process in the container to do damage that would have otherwise been blocked. On the other hand, this allows making use of namespaces/sandboxing inside the container. Upstream LXD has the fix since 2019 which make it less likely to run into problems with the backport. The backported fix was also tested manually to
[Touch-packages] [Bug 1959047] Re: systemd ignores RootDirectory option in .service units
Uploaded to the queue ** Changed in: lxd (Ubuntu Bionic) Status: Confirmed => In Progress -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1959047 Title: systemd ignores RootDirectory option in .service units Status in lxd package in Ubuntu: Invalid Status in systemd package in Ubuntu: Confirmed Status in lxd source package in Bionic: In Progress Status in systemd source package in Bionic: Confirmed Status in systemd source package in Focal: Confirmed Status in systemd source package in Impish: Confirmed Bug description: [Impact] Ubuntu carries a patch on top of systemd [a] to silence namespace set up failures. This is meant as a workaround for a bug in the LXD version shipped in Ubuntu 18.04. Masking namespace set up failures creates a false sense of security for the user/admin. As mentioned in comment #1, systemd upstream explains that silencing this kind of error is dangerous and should be avoided. Backporting the LXD fix [b] to Ubuntu 18.04 would allow namespaces to work inside containers. This is the goal of this SRU. Ultimately, once LXD in Ubuntu 18.04 includes the fix [b], it would be possible to drop the Ubuntu-specific patch for systemd [a]. This is however *not an immediate concern for this SRU*. [Test Plan] 1) Create a 18.04 VM: $ lxc launch images:ubuntu/18.04 lp1959047 --vm $ sleep 30 # give it time to boot 2) Install and initialize LXD in it: $ lxc exec lp1959047 -- apt-get update $ lxc exec lp1959047 -- apt-get install -y lxd $ lxc exec lp1959047 -- lxd init --auto 3) Create a Jammy container and enable systemd debugging: $ lxc exec lp1959047 -- lxc init images:ubuntu/22.04 c1 $ lxc exec lp1959047 -- lxc config set c1 raw.lxc 'lxc.init.cmd = /sbin/init systemd.log_level=debug' $ lxc exec lp1959047 -- lxc start c1 4) Check if namespace set up failures are logged: $ lxc exec lp1959047 -- lxc exec c1 -- journalctl -b0 --grep 'Failed to set up namespace' Mar 24 23:29:19 c1 systemd[99]: systemd-udevd.service: Failed to set up namespace, assuming containerized execution, ignoring: Permission denied Mar 24 23:29:19 c1 systemd[132]: systemd-networkd.service: Failed to set up namespace, assuming containerized execution, ignoring: Permission denied Mar 24 23:29:19 c1 systemd[131]: systemd-logind.service: Failed to set up namespace, assuming containerized execution, ignoring: Permission denied Mar 24 23:29:20 c1 systemd[136]: systemd-resolved.service: Failed to set up namespace, assuming containerized execution, ignoring: Permission denied Mar 24 23:29:20 c1 systemd[128]: e2scrub_reap.service: Failed to set up namespace, assuming containerized execution, ignoring: Permission denied Mar 24 23:29:23 c1 systemd[243]: systemd-hostnamed.service: Failed to set up namespace, assuming containerized execution, ignoring: Permission denied If LXD in Ubuntu 18.04 has the patch, the "Failed to set up namespace" messages wouldn't be there. [Where problems could occur] The LXD fix changes the Apparmor profile used for containers. This essentially loosen the mount restrictions applied to containers. Weakening the Apparmor profile could make it easier for a process in the container to do damage that would have otherwise been blocked. On the other hand, this allows making use of namespaces/sandboxing inside the container. Upstream LXD has the fix since 2019 which make it less likely to run into problems with the backport. The backported fix was also tested manually to ensure LXD still behaved normally and that it avoided the namespace set up failures in Jammy containers. [a]: https://git.launchpad.net/ubuntu/+source/systemd/tree/debian/patches/debian/UBUNTU-Revert-namespace-be-more-careful-when-handling-namespacin.patch?h=ubuntu/jammy [b]: https://github.com/lxc/lxd/commit/a6b780703350faff8328f3d565f6bac7b6dcf59f [Initial bug description] The version of systemd (249.5-2ubuntu4) currently packaged for the Ubuntu development version (22.04 Jammy Jellyfish) totally ignores the RootDirectory= option in systemd service files. With RootDirectory, systemd should start the service after calling chroot() on the supplied directory. To test/reproduce, create a test service file with the following contents: # /etc/systemd/system/lsb-release.service [Unit] Description=LSB Release Information [Service] Type=simple RootDirectory=/var/chroot/trusty ExecStartPre=/bin/pwd ExecStart=/usr/bin/lsb_release -a You should have a chroot environment in the specified RootDirectory, even though you can still deduce if systemd attempted to chroot or not from the resulting error message. In my example, I installed an end-of-life Ubuntu 14.04 Trusty Tahr in the chroot environment. On systems NOT affected by the problem, I get the
[Touch-packages] [Bug 1959047] Re: systemd ignores RootDirectory option in .service units
Status changed to 'Confirmed' because the bug affects multiple users. ** Changed in: systemd (Ubuntu Impish) Status: New => Confirmed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1959047 Title: systemd ignores RootDirectory option in .service units Status in lxd package in Ubuntu: Invalid Status in systemd package in Ubuntu: Confirmed Status in lxd source package in Bionic: In Progress Status in systemd source package in Bionic: Confirmed Status in systemd source package in Focal: Confirmed Status in systemd source package in Impish: Confirmed Bug description: [Impact] Ubuntu carries a patch on top of systemd [a] to silence namespace set up failures. This is meant as a workaround for a bug in the LXD version shipped in Ubuntu 18.04. Masking namespace set up failures creates a false sense of security for the user/admin. As mentioned in comment #1, systemd upstream explains that silencing this kind of error is dangerous and should be avoided. Backporting the LXD fix [b] to Ubuntu 18.04 would allow namespaces to work inside containers. This is the goal of this SRU. Ultimately, once LXD in Ubuntu 18.04 includes the fix [b], it would be possible to drop the Ubuntu-specific patch for systemd [a]. This is however *not an immediate concern for this SRU*. [Test Plan] 1) Create a 18.04 VM: $ lxc launch images:ubuntu/18.04 lp1959047 --vm $ sleep 30 # give it time to boot 2) Install and initialize LXD in it: $ lxc exec lp1959047 -- apt-get update $ lxc exec lp1959047 -- apt-get install -y lxd $ lxc exec lp1959047 -- lxd init --auto 3) Create a Jammy container and enable systemd debugging: $ lxc exec lp1959047 -- lxc init images:ubuntu/22.04 c1 $ lxc exec lp1959047 -- lxc config set c1 raw.lxc 'lxc.init.cmd = /sbin/init systemd.log_level=debug' $ lxc exec lp1959047 -- lxc start c1 4) Check if namespace set up failures are logged: $ lxc exec lp1959047 -- lxc exec c1 -- journalctl -b0 --grep 'Failed to set up namespace' Mar 24 23:29:19 c1 systemd[99]: systemd-udevd.service: Failed to set up namespace, assuming containerized execution, ignoring: Permission denied Mar 24 23:29:19 c1 systemd[132]: systemd-networkd.service: Failed to set up namespace, assuming containerized execution, ignoring: Permission denied Mar 24 23:29:19 c1 systemd[131]: systemd-logind.service: Failed to set up namespace, assuming containerized execution, ignoring: Permission denied Mar 24 23:29:20 c1 systemd[136]: systemd-resolved.service: Failed to set up namespace, assuming containerized execution, ignoring: Permission denied Mar 24 23:29:20 c1 systemd[128]: e2scrub_reap.service: Failed to set up namespace, assuming containerized execution, ignoring: Permission denied Mar 24 23:29:23 c1 systemd[243]: systemd-hostnamed.service: Failed to set up namespace, assuming containerized execution, ignoring: Permission denied If LXD in Ubuntu 18.04 has the patch, the "Failed to set up namespace" messages wouldn't be there. [Where problems could occur] The LXD fix changes the Apparmor profile used for containers. This essentially loosen the mount restrictions applied to containers. Weakening the Apparmor profile could make it easier for a process in the container to do damage that would have otherwise been blocked. On the other hand, this allows making use of namespaces/sandboxing inside the container. Upstream LXD has the fix since 2019 which make it less likely to run into problems with the backport. The backported fix was also tested manually to ensure LXD still behaved normally and that it avoided the namespace set up failures in Jammy containers. [a]: https://git.launchpad.net/ubuntu/+source/systemd/tree/debian/patches/debian/UBUNTU-Revert-namespace-be-more-careful-when-handling-namespacin.patch?h=ubuntu/jammy [b]: https://github.com/lxc/lxd/commit/a6b780703350faff8328f3d565f6bac7b6dcf59f [Initial bug description] The version of systemd (249.5-2ubuntu4) currently packaged for the Ubuntu development version (22.04 Jammy Jellyfish) totally ignores the RootDirectory= option in systemd service files. With RootDirectory, systemd should start the service after calling chroot() on the supplied directory. To test/reproduce, create a test service file with the following contents: # /etc/systemd/system/lsb-release.service [Unit] Description=LSB Release Information [Service] Type=simple RootDirectory=/var/chroot/trusty ExecStartPre=/bin/pwd ExecStart=/usr/bin/lsb_release -a You should have a chroot environment in the specified RootDirectory, even though you can still deduce if systemd attempted to chroot or not from the resulting error message. In my example, I installed an end-of-life Ubuntu 14.04 Trusty Tahr in the chroot environment. On
[Touch-packages] [Bug 1959047] Re: systemd ignores RootDirectory option in .service units
Status changed to 'Confirmed' because the bug affects multiple users. ** Changed in: systemd (Ubuntu Focal) Status: New => Confirmed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1959047 Title: systemd ignores RootDirectory option in .service units Status in lxd package in Ubuntu: Invalid Status in systemd package in Ubuntu: Confirmed Status in lxd source package in Bionic: In Progress Status in systemd source package in Bionic: Confirmed Status in systemd source package in Focal: Confirmed Status in systemd source package in Impish: Confirmed Bug description: [Impact] Ubuntu carries a patch on top of systemd [a] to silence namespace set up failures. This is meant as a workaround for a bug in the LXD version shipped in Ubuntu 18.04. Masking namespace set up failures creates a false sense of security for the user/admin. As mentioned in comment #1, systemd upstream explains that silencing this kind of error is dangerous and should be avoided. Backporting the LXD fix [b] to Ubuntu 18.04 would allow namespaces to work inside containers. This is the goal of this SRU. Ultimately, once LXD in Ubuntu 18.04 includes the fix [b], it would be possible to drop the Ubuntu-specific patch for systemd [a]. This is however *not an immediate concern for this SRU*. [Test Plan] 1) Create a 18.04 VM: $ lxc launch images:ubuntu/18.04 lp1959047 --vm $ sleep 30 # give it time to boot 2) Install and initialize LXD in it: $ lxc exec lp1959047 -- apt-get update $ lxc exec lp1959047 -- apt-get install -y lxd $ lxc exec lp1959047 -- lxd init --auto 3) Create a Jammy container and enable systemd debugging: $ lxc exec lp1959047 -- lxc init images:ubuntu/22.04 c1 $ lxc exec lp1959047 -- lxc config set c1 raw.lxc 'lxc.init.cmd = /sbin/init systemd.log_level=debug' $ lxc exec lp1959047 -- lxc start c1 4) Check if namespace set up failures are logged: $ lxc exec lp1959047 -- lxc exec c1 -- journalctl -b0 --grep 'Failed to set up namespace' Mar 24 23:29:19 c1 systemd[99]: systemd-udevd.service: Failed to set up namespace, assuming containerized execution, ignoring: Permission denied Mar 24 23:29:19 c1 systemd[132]: systemd-networkd.service: Failed to set up namespace, assuming containerized execution, ignoring: Permission denied Mar 24 23:29:19 c1 systemd[131]: systemd-logind.service: Failed to set up namespace, assuming containerized execution, ignoring: Permission denied Mar 24 23:29:20 c1 systemd[136]: systemd-resolved.service: Failed to set up namespace, assuming containerized execution, ignoring: Permission denied Mar 24 23:29:20 c1 systemd[128]: e2scrub_reap.service: Failed to set up namespace, assuming containerized execution, ignoring: Permission denied Mar 24 23:29:23 c1 systemd[243]: systemd-hostnamed.service: Failed to set up namespace, assuming containerized execution, ignoring: Permission denied If LXD in Ubuntu 18.04 has the patch, the "Failed to set up namespace" messages wouldn't be there. [Where problems could occur] The LXD fix changes the Apparmor profile used for containers. This essentially loosen the mount restrictions applied to containers. Weakening the Apparmor profile could make it easier for a process in the container to do damage that would have otherwise been blocked. On the other hand, this allows making use of namespaces/sandboxing inside the container. Upstream LXD has the fix since 2019 which make it less likely to run into problems with the backport. The backported fix was also tested manually to ensure LXD still behaved normally and that it avoided the namespace set up failures in Jammy containers. [a]: https://git.launchpad.net/ubuntu/+source/systemd/tree/debian/patches/debian/UBUNTU-Revert-namespace-be-more-careful-when-handling-namespacin.patch?h=ubuntu/jammy [b]: https://github.com/lxc/lxd/commit/a6b780703350faff8328f3d565f6bac7b6dcf59f [Initial bug description] The version of systemd (249.5-2ubuntu4) currently packaged for the Ubuntu development version (22.04 Jammy Jellyfish) totally ignores the RootDirectory= option in systemd service files. With RootDirectory, systemd should start the service after calling chroot() on the supplied directory. To test/reproduce, create a test service file with the following contents: # /etc/systemd/system/lsb-release.service [Unit] Description=LSB Release Information [Service] Type=simple RootDirectory=/var/chroot/trusty ExecStartPre=/bin/pwd ExecStart=/usr/bin/lsb_release -a You should have a chroot environment in the specified RootDirectory, even though you can still deduce if systemd attempted to chroot or not from the resulting error message. In my example, I installed an end-of-life Ubuntu 14.04 Trusty Tahr in the chroot environment. On
[Touch-packages] [Bug 1959047] Re: systemd ignores RootDirectory option in .service units
Status changed to 'Confirmed' because the bug affects multiple users. ** Changed in: systemd (Ubuntu Bionic) Status: New => Confirmed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1959047 Title: systemd ignores RootDirectory option in .service units Status in lxd package in Ubuntu: Invalid Status in systemd package in Ubuntu: Confirmed Status in lxd source package in Bionic: In Progress Status in systemd source package in Bionic: Confirmed Status in systemd source package in Focal: Confirmed Status in systemd source package in Impish: Confirmed Bug description: [Impact] Ubuntu carries a patch on top of systemd [a] to silence namespace set up failures. This is meant as a workaround for a bug in the LXD version shipped in Ubuntu 18.04. Masking namespace set up failures creates a false sense of security for the user/admin. As mentioned in comment #1, systemd upstream explains that silencing this kind of error is dangerous and should be avoided. Backporting the LXD fix [b] to Ubuntu 18.04 would allow namespaces to work inside containers. This is the goal of this SRU. Ultimately, once LXD in Ubuntu 18.04 includes the fix [b], it would be possible to drop the Ubuntu-specific patch for systemd [a]. This is however *not an immediate concern for this SRU*. [Test Plan] 1) Create a 18.04 VM: $ lxc launch images:ubuntu/18.04 lp1959047 --vm $ sleep 30 # give it time to boot 2) Install and initialize LXD in it: $ lxc exec lp1959047 -- apt-get update $ lxc exec lp1959047 -- apt-get install -y lxd $ lxc exec lp1959047 -- lxd init --auto 3) Create a Jammy container and enable systemd debugging: $ lxc exec lp1959047 -- lxc init images:ubuntu/22.04 c1 $ lxc exec lp1959047 -- lxc config set c1 raw.lxc 'lxc.init.cmd = /sbin/init systemd.log_level=debug' $ lxc exec lp1959047 -- lxc start c1 4) Check if namespace set up failures are logged: $ lxc exec lp1959047 -- lxc exec c1 -- journalctl -b0 --grep 'Failed to set up namespace' Mar 24 23:29:19 c1 systemd[99]: systemd-udevd.service: Failed to set up namespace, assuming containerized execution, ignoring: Permission denied Mar 24 23:29:19 c1 systemd[132]: systemd-networkd.service: Failed to set up namespace, assuming containerized execution, ignoring: Permission denied Mar 24 23:29:19 c1 systemd[131]: systemd-logind.service: Failed to set up namespace, assuming containerized execution, ignoring: Permission denied Mar 24 23:29:20 c1 systemd[136]: systemd-resolved.service: Failed to set up namespace, assuming containerized execution, ignoring: Permission denied Mar 24 23:29:20 c1 systemd[128]: e2scrub_reap.service: Failed to set up namespace, assuming containerized execution, ignoring: Permission denied Mar 24 23:29:23 c1 systemd[243]: systemd-hostnamed.service: Failed to set up namespace, assuming containerized execution, ignoring: Permission denied If LXD in Ubuntu 18.04 has the patch, the "Failed to set up namespace" messages wouldn't be there. [Where problems could occur] The LXD fix changes the Apparmor profile used for containers. This essentially loosen the mount restrictions applied to containers. Weakening the Apparmor profile could make it easier for a process in the container to do damage that would have otherwise been blocked. On the other hand, this allows making use of namespaces/sandboxing inside the container. Upstream LXD has the fix since 2019 which make it less likely to run into problems with the backport. The backported fix was also tested manually to ensure LXD still behaved normally and that it avoided the namespace set up failures in Jammy containers. [a]: https://git.launchpad.net/ubuntu/+source/systemd/tree/debian/patches/debian/UBUNTU-Revert-namespace-be-more-careful-when-handling-namespacin.patch?h=ubuntu/jammy [b]: https://github.com/lxc/lxd/commit/a6b780703350faff8328f3d565f6bac7b6dcf59f [Initial bug description] The version of systemd (249.5-2ubuntu4) currently packaged for the Ubuntu development version (22.04 Jammy Jellyfish) totally ignores the RootDirectory= option in systemd service files. With RootDirectory, systemd should start the service after calling chroot() on the supplied directory. To test/reproduce, create a test service file with the following contents: # /etc/systemd/system/lsb-release.service [Unit] Description=LSB Release Information [Service] Type=simple RootDirectory=/var/chroot/trusty ExecStartPre=/bin/pwd ExecStart=/usr/bin/lsb_release -a You should have a chroot environment in the specified RootDirectory, even though you can still deduce if systemd attempted to chroot or not from the resulting error message. In my example, I installed an end-of-life Ubuntu 14.04 Trusty Tahr in the chroot environment. On
[Touch-packages] [Bug 1959047] Re: systemd ignores RootDirectory option in .service units
Status changed to 'Confirmed' because the bug affects multiple users. ** Changed in: lxd (Ubuntu Bionic) Status: New => Confirmed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1959047 Title: systemd ignores RootDirectory option in .service units Status in lxd package in Ubuntu: Invalid Status in systemd package in Ubuntu: Confirmed Status in lxd source package in Bionic: In Progress Status in systemd source package in Bionic: Confirmed Status in systemd source package in Focal: Confirmed Status in systemd source package in Impish: Confirmed Bug description: [Impact] Ubuntu carries a patch on top of systemd [a] to silence namespace set up failures. This is meant as a workaround for a bug in the LXD version shipped in Ubuntu 18.04. Masking namespace set up failures creates a false sense of security for the user/admin. As mentioned in comment #1, systemd upstream explains that silencing this kind of error is dangerous and should be avoided. Backporting the LXD fix [b] to Ubuntu 18.04 would allow namespaces to work inside containers. This is the goal of this SRU. Ultimately, once LXD in Ubuntu 18.04 includes the fix [b], it would be possible to drop the Ubuntu-specific patch for systemd [a]. This is however *not an immediate concern for this SRU*. [Test Plan] 1) Create a 18.04 VM: $ lxc launch images:ubuntu/18.04 lp1959047 --vm $ sleep 30 # give it time to boot 2) Install and initialize LXD in it: $ lxc exec lp1959047 -- apt-get update $ lxc exec lp1959047 -- apt-get install -y lxd $ lxc exec lp1959047 -- lxd init --auto 3) Create a Jammy container and enable systemd debugging: $ lxc exec lp1959047 -- lxc init images:ubuntu/22.04 c1 $ lxc exec lp1959047 -- lxc config set c1 raw.lxc 'lxc.init.cmd = /sbin/init systemd.log_level=debug' $ lxc exec lp1959047 -- lxc start c1 4) Check if namespace set up failures are logged: $ lxc exec lp1959047 -- lxc exec c1 -- journalctl -b0 --grep 'Failed to set up namespace' Mar 24 23:29:19 c1 systemd[99]: systemd-udevd.service: Failed to set up namespace, assuming containerized execution, ignoring: Permission denied Mar 24 23:29:19 c1 systemd[132]: systemd-networkd.service: Failed to set up namespace, assuming containerized execution, ignoring: Permission denied Mar 24 23:29:19 c1 systemd[131]: systemd-logind.service: Failed to set up namespace, assuming containerized execution, ignoring: Permission denied Mar 24 23:29:20 c1 systemd[136]: systemd-resolved.service: Failed to set up namespace, assuming containerized execution, ignoring: Permission denied Mar 24 23:29:20 c1 systemd[128]: e2scrub_reap.service: Failed to set up namespace, assuming containerized execution, ignoring: Permission denied Mar 24 23:29:23 c1 systemd[243]: systemd-hostnamed.service: Failed to set up namespace, assuming containerized execution, ignoring: Permission denied If LXD in Ubuntu 18.04 has the patch, the "Failed to set up namespace" messages wouldn't be there. [Where problems could occur] The LXD fix changes the Apparmor profile used for containers. This essentially loosen the mount restrictions applied to containers. Weakening the Apparmor profile could make it easier for a process in the container to do damage that would have otherwise been blocked. On the other hand, this allows making use of namespaces/sandboxing inside the container. Upstream LXD has the fix since 2019 which make it less likely to run into problems with the backport. The backported fix was also tested manually to ensure LXD still behaved normally and that it avoided the namespace set up failures in Jammy containers. [a]: https://git.launchpad.net/ubuntu/+source/systemd/tree/debian/patches/debian/UBUNTU-Revert-namespace-be-more-careful-when-handling-namespacin.patch?h=ubuntu/jammy [b]: https://github.com/lxc/lxd/commit/a6b780703350faff8328f3d565f6bac7b6dcf59f [Initial bug description] The version of systemd (249.5-2ubuntu4) currently packaged for the Ubuntu development version (22.04 Jammy Jellyfish) totally ignores the RootDirectory= option in systemd service files. With RootDirectory, systemd should start the service after calling chroot() on the supplied directory. To test/reproduce, create a test service file with the following contents: # /etc/systemd/system/lsb-release.service [Unit] Description=LSB Release Information [Service] Type=simple RootDirectory=/var/chroot/trusty ExecStartPre=/bin/pwd ExecStart=/usr/bin/lsb_release -a You should have a chroot environment in the specified RootDirectory, even though you can still deduce if systemd attempted to chroot or not from the resulting error message. In my example, I installed an end-of-life Ubuntu 14.04 Trusty Tahr in the chroot environment. On systems
[Touch-packages] [Bug 1959047] Re: systemd ignores RootDirectory option in .service units
@stgraber, I added the SRU template, let me know if something's off. Thanks! ** Description changed: + [Impact] + + Ubuntu carries a patch on top of systemd [a] to silence + namespace set up failures. This is meant as a workaround + for a bug in the LXD version shipped in Ubuntu 18.04. + + Masking namespace set up failures creates a false sense of + security for the user/admin. + + As mentioned in comment #1, systemd upstream explains that silencing + this kind of error is dangerous and should be avoided. + + Backporting the LXD fix [b] to Ubuntu 18.04 would allow namespaces + to work inside containers. This is the goal of this SRU. + + Ultimately, once LXD in Ubuntu 18.04 includes the fix [b], it would + be possible to drop the Ubuntu-specific patch for systemd [a]. This + is however *not an immediate concern for this SRU*. + + [Test Plan] + + 1) Create a 18.04 VM: + $ lxc launch images:ubuntu/18.04 lp1959047 --vm + $ sleep 30 # give it time to boot + + 2) Install and initialize LXD in it: + $ lxc exec lp1959047 -- apt-get update + $ lxc exec lp1959047 -- apt-get install -y lxd + $ lxc exec lp1959047 -- lxd init --auto + + 3) Create a Jammy container and enable systemd debugging: + $ lxc exec lp1959047 -- lxc init images:ubuntu/22.04 c1 + $ lxc exec lp1959047 -- lxc config set c1 raw.lxc 'lxc.init.cmd = /sbin/init systemd.log_level=debug' + $ lxc exec lp1959047 -- lxc start c1 + + 4) Check if namespace set up failures are logged: + $ lxc exec lp1959047 -- lxc exec c1 -- journalctl -b0 --grep 'Failed to set up namespace' + Mar 24 23:29:19 c1 systemd[99]: systemd-udevd.service: Failed to set up namespace, assuming containerized execution, ignoring: Permission denied + Mar 24 23:29:19 c1 systemd[132]: systemd-networkd.service: Failed to set up namespace, assuming containerized execution, ignoring: Permission denied + Mar 24 23:29:19 c1 systemd[131]: systemd-logind.service: Failed to set up namespace, assuming containerized execution, ignoring: Permission denied + Mar 24 23:29:20 c1 systemd[136]: systemd-resolved.service: Failed to set up namespace, assuming containerized execution, ignoring: Permission denied + Mar 24 23:29:20 c1 systemd[128]: e2scrub_reap.service: Failed to set up namespace, assuming containerized execution, ignoring: Permission denied + Mar 24 23:29:23 c1 systemd[243]: systemd-hostnamed.service: Failed to set up namespace, assuming containerized execution, ignoring: Permission denied + + If LXD in Ubuntu 18.04 has the patch, the "Failed to set up namespace" + messages wouldn't be there. + + [Where problems could occur] + + The LXD fix changes the Apparmor profile used for containers. This essentially + loosen the mount restrictions applied to containers. + + Weakening the Apparmor profile could make it easier for a process in the container + to do damage that would have otherwise been blocked. On the other hand, this + allows making use of namespaces/sandboxing inside the container. + + Upstream LXD has the fix since 2019 which make it less likely to run into + problems with the backport. + + The backported fix was also tested manually to ensure LXD still behaved normally + and that it avoided the namespace set up failures in Jammy containers. + + [a]: https://git.launchpad.net/ubuntu/+source/systemd/tree/debian/patches/debian/UBUNTU-Revert-namespace-be-more-careful-when-handling-namespacin.patch?h=ubuntu/jammy + [b]: https://github.com/lxc/lxd/commit/a6b780703350faff8328f3d565f6bac7b6dcf59f + + [Initial bug description] + The version of systemd (249.5-2ubuntu4) currently packaged for the Ubuntu development version (22.04 Jammy Jellyfish) totally ignores the RootDirectory= option in systemd service files. With RootDirectory, systemd should start the service after calling chroot() on the supplied directory. To test/reproduce, create a test service file with the following contents: - # /etc/systemd/system/lsb-release.service [Unit] Description=LSB Release Information [Service] Type=simple RootDirectory=/var/chroot/trusty ExecStartPre=/bin/pwd ExecStart=/usr/bin/lsb_release -a - - You should have a chroot environment in the specified RootDirectory, even though you can still deduce if systemd attempted to chroot or not from the resulting error message. + You should have a chroot environment in the specified RootDirectory, + even though you can still deduce if systemd attempted to chroot or not + from the resulting error message. In my example, I installed an end-of-life Ubuntu 14.04 Trusty Tahr in the chroot environment. On systems NOT affected by the problem, I get the following result when I start this test service. This is what I'd expect. - Jan 25 20:40:40 dolly systemd[1]: Starting LSB Release Information... Jan 25 20:40:40 dolly pwd[361]: / Jan 25 20:40:40 dolly systemd[1]: Started LSB Release Information. Jan 25 20:40:40 dolly lsb_release[362]: No LSB modules are available. Jan 25
[Touch-packages] [Bug 1959047] Re: systemd ignores RootDirectory option in .service units
Okay, that looks promising. Can you add the SRU sections to the description describing those testing steps? Then I can upload to the SRU queue referencing this bug. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1959047 Title: systemd ignores RootDirectory option in .service units Status in lxd package in Ubuntu: Invalid Status in systemd package in Ubuntu: Confirmed Status in lxd source package in Bionic: New Status in systemd source package in Bionic: New Status in systemd source package in Focal: New Status in systemd source package in Impish: New Bug description: The version of systemd (249.5-2ubuntu4) currently packaged for the Ubuntu development version (22.04 Jammy Jellyfish) totally ignores the RootDirectory= option in systemd service files. With RootDirectory, systemd should start the service after calling chroot() on the supplied directory. To test/reproduce, create a test service file with the following contents: # /etc/systemd/system/lsb-release.service [Unit] Description=LSB Release Information [Service] Type=simple RootDirectory=/var/chroot/trusty ExecStartPre=/bin/pwd ExecStart=/usr/bin/lsb_release -a You should have a chroot environment in the specified RootDirectory, even though you can still deduce if systemd attempted to chroot or not from the resulting error message. In my example, I installed an end-of-life Ubuntu 14.04 Trusty Tahr in the chroot environment. On systems NOT affected by the problem, I get the following result when I start this test service. This is what I'd expect. Jan 25 20:40:40 dolly systemd[1]: Starting LSB Release Information... Jan 25 20:40:40 dolly pwd[361]: / Jan 25 20:40:40 dolly systemd[1]: Started LSB Release Information. Jan 25 20:40:40 dolly lsb_release[362]: No LSB modules are available. Jan 25 20:40:40 dolly lsb_release[362]: Distributor ID:Ubuntu Jan 25 20:40:40 dolly lsb_release[362]: Description:Ubuntu 14.04 LTS Jan 25 20:40:40 dolly lsb_release[362]: Release:14.04 Jan 25 20:40:40 dolly lsb_release[362]: Codename:trusty Jan 25 20:40:40 dolly systemd[1]: lsb-release.service: Succeeded. On the problematic system, however, I get the following result. Jan 25 21:21:08 savelog systemd[1]: Starting LSB Release Information... Jan 25 21:21:08 savelog systemd[1]: Started LSB Release Information. Jan 25 21:21:08 savelog pwd[81114]: / Jan 25 21:21:08 savelog lsb_release[81115]: No LSB modules are available. Jan 25 21:21:08 savelog lsb_release[81115]: Distributor ID:Ubuntu Jan 25 21:21:08 savelog lsb_release[81115]: Description:Ubuntu Jammy Jellyfish (development branch) Jan 25 21:21:08 savelog lsb_release[81115]: Release:22.04 Jan 25 21:21:08 savelog lsb_release[81115]: Codename:jammy Jan 25 21:21:08 savelog systemd[1]: lsb-release.service: Deactivated successfully. It totally run the service on the host's root filesystem, it didn't care even the slightest that a RootDirectory is specified. Tested on the following releases / systemd versions: Ubuntu 18.04.6 Bionic Beaver – ISSUE NOT PRESENT systemd 237 +PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN2 +IDN -PCRE2 default-hierarchy=hybrid Ubuntu 20.04.3 Focal Fossa – ISSUE NOT PRESENT systemd 245 (245.4-4ubuntu3.15) +PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN2 -IDN +PCRE2 default-hierarchy=hybrid Ubuntu 21.10 Impish Indri – ISSUE NOT PRESENT systemd 248 (248.3-1ubuntu8.2) +PAM +AUDIT +SELINUX +APPARMOR +IMA +SMACK +SECCOMP +GCRYPT +GNUTLS -OPENSSL +ACL +BLKID +CURL +ELFUTILS -FIDO2 +IDN2 -IDN +IPTC +KMOD +LIBCRYPTSETUP -LIBFDISK +PCRE2 -PWQUALITY -P11KIT -QRENCODE +BZIP2 +LZ4 +XZ +ZLIB +ZSTD -XKBCOMMON +UTMP +SYSVINIT default-hierarchy=unified Ubuntu 22.04 Jammy Jellyfish (development branch) – ISSUE PRESENT systemd 249 (249.5-2ubuntu4) +PAM +AUDIT +SELINUX +APPARMOR +IMA +SMACK +SECCOMP +GCRYPT +GNUTLS -OPENSSL +ACL +BLKID +CURL +ELFUTILS -FIDO2 +IDN2 -IDN +IPTC +KMOD +LIBCRYPTSETUP -LIBFDISK +PCRE2 -PWQUALITY -P11KIT -QRENCODE +BZIP2 +LZ4 +XZ +ZLIB +ZSTD -XKBCOMMON +UTMP +SYSVINIT default-hierarchy=unified Note that the problem is produced under an LXC container; since systemd detects virtualization, it might change how it behaves. It's either a bug or an intentional change I don't understand yet (i.e. the RootDirectory option has deprecated and is about to be replaced with something else, or there are additional conditions to be met before RootDirectory is considered), but I think in the latter case I should at least get a warning that there is a change in
[Touch-packages] [Bug 1959047] Re: systemd ignores RootDirectory option in .service units
Thanks @stgraber for providing 3.0.3-0ubuntu1~18.04.2~ppa1 (via https://launchpad.net/~stgraber/+archive/experimental). This allowed me to create a Bionic VM in which I created a Jammy container. The Jammy was then configured to have systemd in debug mode: root@bionic-vm:~# lxc config set c1 raw.lxc 'lxc.init.cmd = /sbin/init systemd.log_level=debug' Then in the container, looking for the "Failed to set up namespace" messaged added by the Ubuntu patch on top of systemd: root@c1:~# journalctl -b0 --grep 'Failed to set up namespace' Mar 24 20:26:32 c1 systemd[100]: systemd-udevd.service: Failed to set up namespace, assuming containerized execution, ignoring: Permission denied Mar 24 20:26:32 c1 systemd[103]: systemd-networkd.service: Failed to set up namespace, assuming containerized execution, ignoring: Permission denied Mar 24 20:26:32 c1 systemd[110]: systemd-logind.service: Failed to set up namespace, assuming containerized execution, ignoring: Permission denied Mar 24 20:26:32 c1 systemd[113]: systemd-resolved.service: Failed to set up namespace, assuming containerized execution, ignoring: Permission denied Mar 24 20:26:33 c1 systemd[114]: systemd-hostnamed.service: Failed to set up namespace, assuming containerized execution, ignoring: Permission denied Mar 24 20:26:33 c1 systemd[107]: e2scrub_reap.service: Failed to set up namespace, assuming containerized execution, ignoring: Permission denied Now if LXD in the Bionic VM is upgraded from 3.0.3-0ubuntu1~18.04.2 to 3.0.3-0ubuntu1~18.04.2~ppa1: root@bionic-vm:~# apt-get dist-upgrade -y ... The following packages will be upgraded: lxd lxd-client 2 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. Need to get 8,335 kB of archives. After this operation, 20.5 kB of additional disk space will be used. Get:1 https://ppa.launchpadcontent.net/stgraber/experimental/ubuntu bionic/main amd64 lxd amd64 3.0.3-0ubuntu1~18.04.2~ppa1 [5,260 kB] Get:2 https://ppa.launchpadcontent.net/stgraber/experimental/ubuntu bionic/main amd64 lxd-client amd64 3.0.3-0ubuntu1~18.04.2~ppa1 [3,075 kB] Fetched 8,335 kB in 4s (1,990 kB/s) ... The namespace setup no longer fails as we see no *new* entries in the journal: root@c1:~# journalctl -b0 --grep 'Failed to set up namespace'containerized execution, ignoring: Permission denied Mar 24 20:26:32 c1 systemd[100]: systemd-udevd.service: Failed to set up namespace, assuming containerized execution, ignoring: Permission denied Mar 24 20:26:32 c1 systemd[103]: systemd-networkd.service: Failed to set up namespace, assuming containerized execution, ignoring: Permission denied Mar 24 20:26:32 c1 systemd[110]: systemd-logind.service: Failed to set up namespace, assuming containerized execution, ignoring: Permission denied Mar 24 20:26:32 c1 systemd[113]: systemd-resolved.service: Failed to set up namespace, assuming containerized execution, ignoring: Permission denied Mar 24 20:26:33 c1 systemd[114]: systemd-hostnamed.service: Failed to set up namespace, assuming containerized execution, ignoring: Permission denied Mar 24 20:26:33 c1 systemd[107]: e2scrub_reap.service: Failed to set up namespace, assuming containerized execution, ignoring: Permission denied -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1959047 Title: systemd ignores RootDirectory option in .service units Status in lxd package in Ubuntu: Invalid Status in systemd package in Ubuntu: Confirmed Status in lxd source package in Bionic: New Status in systemd source package in Bionic: New Status in systemd source package in Focal: New Status in systemd source package in Impish: New Bug description: The version of systemd (249.5-2ubuntu4) currently packaged for the Ubuntu development version (22.04 Jammy Jellyfish) totally ignores the RootDirectory= option in systemd service files. With RootDirectory, systemd should start the service after calling chroot() on the supplied directory. To test/reproduce, create a test service file with the following contents: # /etc/systemd/system/lsb-release.service [Unit] Description=LSB Release Information [Service] Type=simple RootDirectory=/var/chroot/trusty ExecStartPre=/bin/pwd ExecStart=/usr/bin/lsb_release -a You should have a chroot environment in the specified RootDirectory, even though you can still deduce if systemd attempted to chroot or not from the resulting error message. In my example, I installed an end-of-life Ubuntu 14.04 Trusty Tahr in the chroot environment. On systems NOT affected by the problem, I get the following result when I start this test service. This is what I'd expect. Jan 25 20:40:40 dolly systemd[1]: Starting LSB Release Information... Jan 25 20:40:40 dolly pwd[361]: / Jan 25 20:40:40 dolly systemd[1]: Started LSB Release Information. Jan 25 20:40:40 dolly lsb_release[362]:
[Touch-packages] [Bug 1959047] Re: systemd ignores RootDirectory option in .service units
Uploading a LXD SRU to bionic with the one commit cherry-picked shouldn't be too hard. But we'd need someone to sort out the SRU paperwork as I have no idea how we'd even test the fix. ** Changed in: lxd (Ubuntu) Status: New => Invalid -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1959047 Title: systemd ignores RootDirectory option in .service units Status in lxd package in Ubuntu: Invalid Status in systemd package in Ubuntu: Confirmed Status in lxd source package in Bionic: New Status in systemd source package in Bionic: New Status in systemd source package in Focal: New Status in systemd source package in Impish: New Bug description: The version of systemd (249.5-2ubuntu4) currently packaged for the Ubuntu development version (22.04 Jammy Jellyfish) totally ignores the RootDirectory= option in systemd service files. With RootDirectory, systemd should start the service after calling chroot() on the supplied directory. To test/reproduce, create a test service file with the following contents: # /etc/systemd/system/lsb-release.service [Unit] Description=LSB Release Information [Service] Type=simple RootDirectory=/var/chroot/trusty ExecStartPre=/bin/pwd ExecStart=/usr/bin/lsb_release -a You should have a chroot environment in the specified RootDirectory, even though you can still deduce if systemd attempted to chroot or not from the resulting error message. In my example, I installed an end-of-life Ubuntu 14.04 Trusty Tahr in the chroot environment. On systems NOT affected by the problem, I get the following result when I start this test service. This is what I'd expect. Jan 25 20:40:40 dolly systemd[1]: Starting LSB Release Information... Jan 25 20:40:40 dolly pwd[361]: / Jan 25 20:40:40 dolly systemd[1]: Started LSB Release Information. Jan 25 20:40:40 dolly lsb_release[362]: No LSB modules are available. Jan 25 20:40:40 dolly lsb_release[362]: Distributor ID:Ubuntu Jan 25 20:40:40 dolly lsb_release[362]: Description:Ubuntu 14.04 LTS Jan 25 20:40:40 dolly lsb_release[362]: Release:14.04 Jan 25 20:40:40 dolly lsb_release[362]: Codename:trusty Jan 25 20:40:40 dolly systemd[1]: lsb-release.service: Succeeded. On the problematic system, however, I get the following result. Jan 25 21:21:08 savelog systemd[1]: Starting LSB Release Information... Jan 25 21:21:08 savelog systemd[1]: Started LSB Release Information. Jan 25 21:21:08 savelog pwd[81114]: / Jan 25 21:21:08 savelog lsb_release[81115]: No LSB modules are available. Jan 25 21:21:08 savelog lsb_release[81115]: Distributor ID:Ubuntu Jan 25 21:21:08 savelog lsb_release[81115]: Description:Ubuntu Jammy Jellyfish (development branch) Jan 25 21:21:08 savelog lsb_release[81115]: Release:22.04 Jan 25 21:21:08 savelog lsb_release[81115]: Codename:jammy Jan 25 21:21:08 savelog systemd[1]: lsb-release.service: Deactivated successfully. It totally run the service on the host's root filesystem, it didn't care even the slightest that a RootDirectory is specified. Tested on the following releases / systemd versions: Ubuntu 18.04.6 Bionic Beaver – ISSUE NOT PRESENT systemd 237 +PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN2 +IDN -PCRE2 default-hierarchy=hybrid Ubuntu 20.04.3 Focal Fossa – ISSUE NOT PRESENT systemd 245 (245.4-4ubuntu3.15) +PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN2 -IDN +PCRE2 default-hierarchy=hybrid Ubuntu 21.10 Impish Indri – ISSUE NOT PRESENT systemd 248 (248.3-1ubuntu8.2) +PAM +AUDIT +SELINUX +APPARMOR +IMA +SMACK +SECCOMP +GCRYPT +GNUTLS -OPENSSL +ACL +BLKID +CURL +ELFUTILS -FIDO2 +IDN2 -IDN +IPTC +KMOD +LIBCRYPTSETUP -LIBFDISK +PCRE2 -PWQUALITY -P11KIT -QRENCODE +BZIP2 +LZ4 +XZ +ZLIB +ZSTD -XKBCOMMON +UTMP +SYSVINIT default-hierarchy=unified Ubuntu 22.04 Jammy Jellyfish (development branch) – ISSUE PRESENT systemd 249 (249.5-2ubuntu4) +PAM +AUDIT +SELINUX +APPARMOR +IMA +SMACK +SECCOMP +GCRYPT +GNUTLS -OPENSSL +ACL +BLKID +CURL +ELFUTILS -FIDO2 +IDN2 -IDN +IPTC +KMOD +LIBCRYPTSETUP -LIBFDISK +PCRE2 -PWQUALITY -P11KIT -QRENCODE +BZIP2 +LZ4 +XZ +ZLIB +ZSTD -XKBCOMMON +UTMP +SYSVINIT default-hierarchy=unified Note that the problem is produced under an LXC container; since systemd detects virtualization, it might change how it behaves. It's either a bug or an intentional change I don't understand yet (i.e. the RootDirectory option has deprecated and is about to be replaced with something else, or there are additional conditions to be met before RootDirectory is considered), but I
[Touch-packages] [Bug 1959047] Re: systemd ignores RootDirectory option in .service units
This is still present in jammy as debian/patches/debian/UBUNTU-Revert-namespace-be-more-careful-when-handling-namespacin.patch If we want to keep this as long as there could be an 18.04 that is like 2028 at least. So AFAIU this bug is actually asking LXD to consider a backport (if possible) to then drop the revert from systemd (all releases). ** Also affects: lxd (Ubuntu) Importance: Undecided Status: New ** Also affects: systemd (Ubuntu Focal) Importance: Undecided Status: New ** Also affects: lxd (Ubuntu Focal) Importance: Undecided Status: New ** Also affects: systemd (Ubuntu Bionic) Importance: Undecided Status: New ** Also affects: lxd (Ubuntu Bionic) Importance: Undecided Status: New ** Also affects: systemd (Ubuntu Impish) Importance: Undecided Status: New ** Also affects: lxd (Ubuntu Impish) Importance: Undecided Status: New ** No longer affects: lxd (Ubuntu Focal) ** No longer affects: lxd (Ubuntu Impish) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1959047 Title: systemd ignores RootDirectory option in .service units Status in lxd package in Ubuntu: New Status in systemd package in Ubuntu: Confirmed Status in lxd source package in Bionic: New Status in systemd source package in Bionic: New Status in systemd source package in Focal: New Status in systemd source package in Impish: New Bug description: The version of systemd (249.5-2ubuntu4) currently packaged for the Ubuntu development version (22.04 Jammy Jellyfish) totally ignores the RootDirectory= option in systemd service files. With RootDirectory, systemd should start the service after calling chroot() on the supplied directory. To test/reproduce, create a test service file with the following contents: # /etc/systemd/system/lsb-release.service [Unit] Description=LSB Release Information [Service] Type=simple RootDirectory=/var/chroot/trusty ExecStartPre=/bin/pwd ExecStart=/usr/bin/lsb_release -a You should have a chroot environment in the specified RootDirectory, even though you can still deduce if systemd attempted to chroot or not from the resulting error message. In my example, I installed an end-of-life Ubuntu 14.04 Trusty Tahr in the chroot environment. On systems NOT affected by the problem, I get the following result when I start this test service. This is what I'd expect. Jan 25 20:40:40 dolly systemd[1]: Starting LSB Release Information... Jan 25 20:40:40 dolly pwd[361]: / Jan 25 20:40:40 dolly systemd[1]: Started LSB Release Information. Jan 25 20:40:40 dolly lsb_release[362]: No LSB modules are available. Jan 25 20:40:40 dolly lsb_release[362]: Distributor ID:Ubuntu Jan 25 20:40:40 dolly lsb_release[362]: Description:Ubuntu 14.04 LTS Jan 25 20:40:40 dolly lsb_release[362]: Release:14.04 Jan 25 20:40:40 dolly lsb_release[362]: Codename:trusty Jan 25 20:40:40 dolly systemd[1]: lsb-release.service: Succeeded. On the problematic system, however, I get the following result. Jan 25 21:21:08 savelog systemd[1]: Starting LSB Release Information... Jan 25 21:21:08 savelog systemd[1]: Started LSB Release Information. Jan 25 21:21:08 savelog pwd[81114]: / Jan 25 21:21:08 savelog lsb_release[81115]: No LSB modules are available. Jan 25 21:21:08 savelog lsb_release[81115]: Distributor ID:Ubuntu Jan 25 21:21:08 savelog lsb_release[81115]: Description:Ubuntu Jammy Jellyfish (development branch) Jan 25 21:21:08 savelog lsb_release[81115]: Release:22.04 Jan 25 21:21:08 savelog lsb_release[81115]: Codename:jammy Jan 25 21:21:08 savelog systemd[1]: lsb-release.service: Deactivated successfully. It totally run the service on the host's root filesystem, it didn't care even the slightest that a RootDirectory is specified. Tested on the following releases / systemd versions: Ubuntu 18.04.6 Bionic Beaver – ISSUE NOT PRESENT systemd 237 +PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN2 +IDN -PCRE2 default-hierarchy=hybrid Ubuntu 20.04.3 Focal Fossa – ISSUE NOT PRESENT systemd 245 (245.4-4ubuntu3.15) +PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN2 -IDN +PCRE2 default-hierarchy=hybrid Ubuntu 21.10 Impish Indri – ISSUE NOT PRESENT systemd 248 (248.3-1ubuntu8.2) +PAM +AUDIT +SELINUX +APPARMOR +IMA +SMACK +SECCOMP +GCRYPT +GNUTLS -OPENSSL +ACL +BLKID +CURL +ELFUTILS -FIDO2 +IDN2 -IDN +IPTC +KMOD +LIBCRYPTSETUP -LIBFDISK +PCRE2 -PWQUALITY -P11KIT -QRENCODE +BZIP2 +LZ4 +XZ +ZLIB +ZSTD -XKBCOMMON +UTMP +SYSVINIT default-hierarchy=unified Ubuntu 22.04
[Touch-packages] [Bug 1959047] Re: systemd ignores RootDirectory option in .service units
Is there a chance to SRU a targeted patch for LXD in Bionic to fix the issue instead? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1959047 Title: systemd ignores RootDirectory option in .service units Status in systemd package in Ubuntu: Confirmed Bug description: The version of systemd (249.5-2ubuntu4) currently packaged for the Ubuntu development version (22.04 Jammy Jellyfish) totally ignores the RootDirectory= option in systemd service files. With RootDirectory, systemd should start the service after calling chroot() on the supplied directory. To test/reproduce, create a test service file with the following contents: # /etc/systemd/system/lsb-release.service [Unit] Description=LSB Release Information [Service] Type=simple RootDirectory=/var/chroot/trusty ExecStartPre=/bin/pwd ExecStart=/usr/bin/lsb_release -a You should have a chroot environment in the specified RootDirectory, even though you can still deduce if systemd attempted to chroot or not from the resulting error message. In my example, I installed an end-of-life Ubuntu 14.04 Trusty Tahr in the chroot environment. On systems NOT affected by the problem, I get the following result when I start this test service. This is what I'd expect. Jan 25 20:40:40 dolly systemd[1]: Starting LSB Release Information... Jan 25 20:40:40 dolly pwd[361]: / Jan 25 20:40:40 dolly systemd[1]: Started LSB Release Information. Jan 25 20:40:40 dolly lsb_release[362]: No LSB modules are available. Jan 25 20:40:40 dolly lsb_release[362]: Distributor ID:Ubuntu Jan 25 20:40:40 dolly lsb_release[362]: Description:Ubuntu 14.04 LTS Jan 25 20:40:40 dolly lsb_release[362]: Release:14.04 Jan 25 20:40:40 dolly lsb_release[362]: Codename:trusty Jan 25 20:40:40 dolly systemd[1]: lsb-release.service: Succeeded. On the problematic system, however, I get the following result. Jan 25 21:21:08 savelog systemd[1]: Starting LSB Release Information... Jan 25 21:21:08 savelog systemd[1]: Started LSB Release Information. Jan 25 21:21:08 savelog pwd[81114]: / Jan 25 21:21:08 savelog lsb_release[81115]: No LSB modules are available. Jan 25 21:21:08 savelog lsb_release[81115]: Distributor ID:Ubuntu Jan 25 21:21:08 savelog lsb_release[81115]: Description:Ubuntu Jammy Jellyfish (development branch) Jan 25 21:21:08 savelog lsb_release[81115]: Release:22.04 Jan 25 21:21:08 savelog lsb_release[81115]: Codename:jammy Jan 25 21:21:08 savelog systemd[1]: lsb-release.service: Deactivated successfully. It totally run the service on the host's root filesystem, it didn't care even the slightest that a RootDirectory is specified. Tested on the following releases / systemd versions: Ubuntu 18.04.6 Bionic Beaver – ISSUE NOT PRESENT systemd 237 +PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN2 +IDN -PCRE2 default-hierarchy=hybrid Ubuntu 20.04.3 Focal Fossa – ISSUE NOT PRESENT systemd 245 (245.4-4ubuntu3.15) +PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN2 -IDN +PCRE2 default-hierarchy=hybrid Ubuntu 21.10 Impish Indri – ISSUE NOT PRESENT systemd 248 (248.3-1ubuntu8.2) +PAM +AUDIT +SELINUX +APPARMOR +IMA +SMACK +SECCOMP +GCRYPT +GNUTLS -OPENSSL +ACL +BLKID +CURL +ELFUTILS -FIDO2 +IDN2 -IDN +IPTC +KMOD +LIBCRYPTSETUP -LIBFDISK +PCRE2 -PWQUALITY -P11KIT -QRENCODE +BZIP2 +LZ4 +XZ +ZLIB +ZSTD -XKBCOMMON +UTMP +SYSVINIT default-hierarchy=unified Ubuntu 22.04 Jammy Jellyfish (development branch) – ISSUE PRESENT systemd 249 (249.5-2ubuntu4) +PAM +AUDIT +SELINUX +APPARMOR +IMA +SMACK +SECCOMP +GCRYPT +GNUTLS -OPENSSL +ACL +BLKID +CURL +ELFUTILS -FIDO2 +IDN2 -IDN +IPTC +KMOD +LIBCRYPTSETUP -LIBFDISK +PCRE2 -PWQUALITY -P11KIT -QRENCODE +BZIP2 +LZ4 +XZ +ZLIB +ZSTD -XKBCOMMON +UTMP +SYSVINIT default-hierarchy=unified Note that the problem is produced under an LXC container; since systemd detects virtualization, it might change how it behaves. It's either a bug or an intentional change I don't understand yet (i.e. the RootDirectory option has deprecated and is about to be replaced with something else, or there are additional conditions to be met before RootDirectory is considered), but I think in the latter case I should at least get a warning that there is a change in configuration. I imagine suddenly everyone's existing service units utilizing RootDirectory silently stop working without any information regarding why. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1959047/+subscriptions -- Mailing list:
[Touch-packages] [Bug 1959047] Re: systemd ignores RootDirectory option in .service units
This is caused by https://git.launchpad.net/ubuntu/+source/systemd/tree/debian/patches/debian/UBUNTU- Revert-namespace-be-more-careful-when-handling- namespacin.patch?h=ubuntu/jammy From upstream's point of view, ignoring sandboxing options requested by unit owners is quite dangerous. It can result in programs running completely unconstrained. See: https://github.com/systemd/systemd/issues/22760 ** Bug watch added: github.com/systemd/systemd/issues #22760 https://github.com/systemd/systemd/issues/22760 ** Changed in: systemd (Ubuntu) Status: New => Confirmed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1959047 Title: systemd ignores RootDirectory option in .service units Status in systemd package in Ubuntu: Confirmed Bug description: The version of systemd (249.5-2ubuntu4) currently packaged for the Ubuntu development version (22.04 Jammy Jellyfish) totally ignores the RootDirectory= option in systemd service files. With RootDirectory, systemd should start the service after calling chroot() on the supplied directory. To test/reproduce, create a test service file with the following contents: # /etc/systemd/system/lsb-release.service [Unit] Description=LSB Release Information [Service] Type=simple RootDirectory=/var/chroot/trusty ExecStartPre=/bin/pwd ExecStart=/usr/bin/lsb_release -a You should have a chroot environment in the specified RootDirectory, even though you can still deduce if systemd attempted to chroot or not from the resulting error message. In my example, I installed an end-of-life Ubuntu 14.04 Trusty Tahr in the chroot environment. On systems NOT affected by the problem, I get the following result when I start this test service. This is what I'd expect. Jan 25 20:40:40 dolly systemd[1]: Starting LSB Release Information... Jan 25 20:40:40 dolly pwd[361]: / Jan 25 20:40:40 dolly systemd[1]: Started LSB Release Information. Jan 25 20:40:40 dolly lsb_release[362]: No LSB modules are available. Jan 25 20:40:40 dolly lsb_release[362]: Distributor ID:Ubuntu Jan 25 20:40:40 dolly lsb_release[362]: Description:Ubuntu 14.04 LTS Jan 25 20:40:40 dolly lsb_release[362]: Release:14.04 Jan 25 20:40:40 dolly lsb_release[362]: Codename:trusty Jan 25 20:40:40 dolly systemd[1]: lsb-release.service: Succeeded. On the problematic system, however, I get the following result. Jan 25 21:21:08 savelog systemd[1]: Starting LSB Release Information... Jan 25 21:21:08 savelog systemd[1]: Started LSB Release Information. Jan 25 21:21:08 savelog pwd[81114]: / Jan 25 21:21:08 savelog lsb_release[81115]: No LSB modules are available. Jan 25 21:21:08 savelog lsb_release[81115]: Distributor ID:Ubuntu Jan 25 21:21:08 savelog lsb_release[81115]: Description:Ubuntu Jammy Jellyfish (development branch) Jan 25 21:21:08 savelog lsb_release[81115]: Release:22.04 Jan 25 21:21:08 savelog lsb_release[81115]: Codename:jammy Jan 25 21:21:08 savelog systemd[1]: lsb-release.service: Deactivated successfully. It totally run the service on the host's root filesystem, it didn't care even the slightest that a RootDirectory is specified. Tested on the following releases / systemd versions: Ubuntu 18.04.6 Bionic Beaver – ISSUE NOT PRESENT systemd 237 +PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN2 +IDN -PCRE2 default-hierarchy=hybrid Ubuntu 20.04.3 Focal Fossa – ISSUE NOT PRESENT systemd 245 (245.4-4ubuntu3.15) +PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN2 -IDN +PCRE2 default-hierarchy=hybrid Ubuntu 21.10 Impish Indri – ISSUE NOT PRESENT systemd 248 (248.3-1ubuntu8.2) +PAM +AUDIT +SELINUX +APPARMOR +IMA +SMACK +SECCOMP +GCRYPT +GNUTLS -OPENSSL +ACL +BLKID +CURL +ELFUTILS -FIDO2 +IDN2 -IDN +IPTC +KMOD +LIBCRYPTSETUP -LIBFDISK +PCRE2 -PWQUALITY -P11KIT -QRENCODE +BZIP2 +LZ4 +XZ +ZLIB +ZSTD -XKBCOMMON +UTMP +SYSVINIT default-hierarchy=unified Ubuntu 22.04 Jammy Jellyfish (development branch) – ISSUE PRESENT systemd 249 (249.5-2ubuntu4) +PAM +AUDIT +SELINUX +APPARMOR +IMA +SMACK +SECCOMP +GCRYPT +GNUTLS -OPENSSL +ACL +BLKID +CURL +ELFUTILS -FIDO2 +IDN2 -IDN +IPTC +KMOD +LIBCRYPTSETUP -LIBFDISK +PCRE2 -PWQUALITY -P11KIT -QRENCODE +BZIP2 +LZ4 +XZ +ZLIB +ZSTD -XKBCOMMON +UTMP +SYSVINIT default-hierarchy=unified Note that the problem is produced under an LXC container; since systemd detects virtualization, it might change how it behaves. It's either a bug or an intentional change I don't understand yet (i.e. the RootDirectory option has deprecated and is about to be replaced with something else,
