[Touch-packages] [Bug 1732411] Re: On upgrade, daemon-reexec should only be issued if safe
A fix [1] in LXC was pushed recently and actually allows systemd daemon- reexec without the cap sys_admin in a container. We tested that it totally solved the issue for us. Would it possible to move this bug report to the LXC project? And to ask for a backport of such fix to Xenial LXC? Thanks! [1] https://github.com/lxc/lxc/commit/af949cc1938ff3a4e06148867a64d7715ce89a50 -- 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/1732411 Title: On upgrade, daemon-reexec should only be issued if safe Status in lxc package in Ubuntu: Invalid Status in systemd package in Ubuntu: New Bug description: Dear all, Following up the bug #1713674, when executing systemd in a hardened LXC context, it might not be suitable to reexec systemd daemon, that would not be able to perform. For instance, in our LXC, we drop several capabilities, including sys_admin and we set /sys to read-only (in which, systemd will find its cgroups). This means, systemd cannot be reexecuted, it will fail to restart and will freeze (properly) at restart making the LXC container in frozen state (still working, but no new services startable, no interaction with systemd possible anymore). When upgrading systemd the debian package, as postinst, will always attempt to reexecute systemd, possibly breaking every other upgrade where a daemon restart is made in postinst, and leaving the system in a degraded state. It would likely be appropriate the check whether the reexecute can work will before performing it: checking capabilities, sys mount point perms, etc. If not applicable, not performing a reexucte and possibly print a message to the user. Occurs with Ubuntu Xenial 16.04.3 LTS and systemd 229-4ubuntu21. Cheers To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1732411/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1732411] Re: On upgrade, daemon-reexec should only be issued if safe
>From our analysis, we indeed agree with the fact that it has nothing to do >with LXC (hence the report in the systemd tracker). We believe that only the package is faulty here and should not attempt to blindly reexec systemd on upgrade. -- 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/1732411 Title: On upgrade, daemon-reexec should only be issued if safe Status in lxc package in Ubuntu: Invalid Status in systemd package in Ubuntu: New Bug description: Dear all, Following up the bug report #1713674, when executing systemd in a hardened LXC context, it might not be suitable to reexec systemd daemon, that would not be able to perform. For instance, in our LXC, we drop several capabilities, including sys_admin and we set /sys to read-only (in which, systemd will find its cgroups). This means, systemd cannot be reexecuted, it will fail to restart and will freeze (properly) at restart making the LXC container in frozen state (still working, but no new services startable, no interaction with systemd possible anymore). When upgrading systemd the debian package, as postinst, will always attempt to reexecute systemd, possibly breaking every other upgrade where a daemon restart is made in postinst, and leaving the system in a degraded state. It would likely be appropriate the check whether the reexecute can work will before performing it: checking capabilities, sys mount point perms, etc. If not applicable, not performing a reexucte and possibly print a message to the user. Occurs with Ubuntu Xenial 16.04.3 LTS and systemd 229-4ubuntu21. Cheers To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1732411/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1732411] [NEW] On upgrade, daemon-reexec should only be issued if safe
Public bug reported: Dear all, Following up the bug report #1713674, when executing systemd in a hardened LXC context, it might not be suitable to reexec systemd daemon, that would not be able to perform. For instance, in our LXC, we drop several capabilities, including sys_admin and we set /sys to read-only (in which, systemd will find its cgroups). This means, systemd cannot be reexecuted, it will fail to restart and will freeze (properly) at restart making the LXC container in frozen state (still working, but no new services startable, no interaction with systemd possible anymore). When upgrading systemd the debian package, as postinst, will always attempt to reexecute systemd, possibly breaking every other upgrade where a daemon restart is made in postinst, and leaving the system in a degraded state. It would likely be appropriate the check whether the reexecute can work will before performing it: checking capabilities, sys mount point perms, etc. If not applicable, not performing a reexucte and possibly print a message to the user. Occurs with Ubuntu Xenial 16.04.3 LTS and systemd 229-4ubuntu21. Cheers ** Affects: systemd (Ubuntu) Importance: Undecided Status: New -- 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/1732411 Title: On upgrade, daemon-reexec should only be issued if safe Status in systemd package in Ubuntu: New Bug description: Dear all, Following up the bug report #1713674, when executing systemd in a hardened LXC context, it might not be suitable to reexec systemd daemon, that would not be able to perform. For instance, in our LXC, we drop several capabilities, including sys_admin and we set /sys to read-only (in which, systemd will find its cgroups). This means, systemd cannot be reexecuted, it will fail to restart and will freeze (properly) at restart making the LXC container in frozen state (still working, but no new services startable, no interaction with systemd possible anymore). When upgrading systemd the debian package, as postinst, will always attempt to reexecute systemd, possibly breaking every other upgrade where a daemon restart is made in postinst, and leaving the system in a degraded state. It would likely be appropriate the check whether the reexecute can work will before performing it: checking capabilities, sys mount point perms, etc. If not applicable, not performing a reexucte and possibly print a message to the user. Occurs with Ubuntu Xenial 16.04.3 LTS and systemd 229-4ubuntu21. Cheers To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1732411/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1713674] [NEW] Starting Xenial lxc without cap_sysadmin fails
Public bug reported: Dear all, When trying to start an LXC container with Xenial on both host and container, if sys_admin capability is dropped (lxc.cap.drop = sys_admin in the config file), the container fails to start, because systemd fails to mount the cgroup filesystem in the container. The workaround is to manually mount the cgroup filesystem before starting the container (using the lxc.mount.entry in the config file), but, LXC performs the mount too early, before being in the container cgroup namespace, that means what's mounted matches host cgroup namespace, not container namespace. The bug was already reported upstream[1][2], but didn't make it to Ubuntu yet, AFAIK. A fix was merged in master[3], would it be possible to have it in Ubuntu Xenial? So far, we manually patch Ubuntu LXC packages with that patch and observed no régressions. Thanks! Cheers, P. Schweitzer [1]: https://github.com/lxc/lxc/pull/1597 [2]: https://github.com/lxc/lxc/pull/1606 [3]: https://github.com/lxc/lxc/commit/c1cecfdd050818865653d7941d7bae5d755246ae ** Affects: lxc (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lxc in Ubuntu. https://bugs.launchpad.net/bugs/1713674 Title: Starting Xenial lxc without cap_sysadmin fails Status in lxc package in Ubuntu: New Bug description: Dear all, When trying to start an LXC container with Xenial on both host and container, if sys_admin capability is dropped (lxc.cap.drop = sys_admin in the config file), the container fails to start, because systemd fails to mount the cgroup filesystem in the container. The workaround is to manually mount the cgroup filesystem before starting the container (using the lxc.mount.entry in the config file), but, LXC performs the mount too early, before being in the container cgroup namespace, that means what's mounted matches host cgroup namespace, not container namespace. The bug was already reported upstream[1][2], but didn't make it to Ubuntu yet, AFAIK. A fix was merged in master[3], would it be possible to have it in Ubuntu Xenial? So far, we manually patch Ubuntu LXC packages with that patch and observed no régressions. Thanks! Cheers, P. Schweitzer [1]: https://github.com/lxc/lxc/pull/1597 [2]: https://github.com/lxc/lxc/pull/1606 [3]: https://github.com/lxc/lxc/commit/c1cecfdd050818865653d7941d7bae5d755246ae To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1713674/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1594422] [NEW] Lambdas with variadic template fail to build
Public bug reported: Dear all, All the G++ shipped with Ubuntu 14.04 (including the latest 4.8 package) are suffering a bug from G++ in the C++11 implementation. It is not possible to build code that contains variadic templates with variadic lambda. The bug was fixed upstream. Would it be possible to backport the fix? As an example, you'll find the upstream bug report: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41933 It provides examples about how to reproduce the bug. The output of the compiler is slightly different though, as it is made by G++-4.8. Cheers ** Affects: gcc-4.8 (Ubuntu) Importance: Undecided Status: New ** Tags: trusty -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gcc-4.8 in Ubuntu. https://bugs.launchpad.net/bugs/1594422 Title: Lambdas with variadic template fail to build Status in gcc-4.8 package in Ubuntu: New Bug description: Dear all, All the G++ shipped with Ubuntu 14.04 (including the latest 4.8 package) are suffering a bug from G++ in the C++11 implementation. It is not possible to build code that contains variadic templates with variadic lambda. The bug was fixed upstream. Would it be possible to backport the fix? As an example, you'll find the upstream bug report: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41933 It provides examples about how to reproduce the bug. The output of the compiler is slightly different though, as it is made by G++-4.8. Cheers To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gcc-4.8/+bug/1594422/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
