FS#61313 - [systemd] 240.0-3 -networkd.service not starting in unprivileged container

Attached to Project: Arch Linux
Opened by ipp (n8V8r) - Tuesday, 08 January 2019, 23:10 GMT
Last edited by Dave Reisner (falconindy) - Thursday, 10 January 2019, 15:38 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To No-one
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description: After having upgraded systemd from 239.370-1 to 240.0-3 in an unprivileged lxc container networkd.service is producing

>> systemd-networkd.service: Failed to set up mount namespacing: Permission denied

Another arch guest on the same host and still with systemd 239.370-1 does not exhibit the issue.

Steps to reproduce:

* pacman -Suy
* accept the update
* restart lxc container
This task depends upon

Closed by  Dave Reisner (falconindy)
Thursday, 10 January 2019, 15:38 GMT
Reason for closing:  Won't fix
Additional comments about closing:  Not Arch's bug to fix. This is upstream in LXC+AA:

https://bugs.launchpad.net/ubuntu/+sourc e/apparmor/+bug/1811248
https://github.com/lxc/lxc/issues/2778
Comment by ipp (n8V8r) - Tuesday, 08 January 2019, 23:35 GMT
For completeness sake it is lxc 3.0.3 on the host.
Comment by loqs (loqs) - Wednesday, 09 January 2019, 00:43 GMT
Please try reverting https://github.com/systemd/systemd/commit/1beab8b0d0
Comment by ipp (n8V8r) - Wednesday, 09 January 2019, 00:54 GMT
that was already merged into 239.370, to my understanding? And 239.370 does not exhibit the issue.
Comment by loqs (loqs) - Wednesday, 09 January 2019, 01:11 GMT
From https://git.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/systemd&id=12d4b723833d67c5d14ec43e5322e8e28dc2a42d the commit used for 239.370 was 3bf819c4ca718a6bc4b3b871cf52a0d1b518967d
Looking at the https://github.com/systemd/systemd-stable/blob/3bf819c4ca718a6bc4b3b871cf52a0d1b518967d/src/core/execute.c#L2383 that to me looks like the code without 1beab8b0d0.
Comment by ipp (n8V8r) - Wednesday, 09 January 2019, 01:21 GMT
I c see. Strange that it was committed despite the voiced concerns.

I suppose the suggestion to revert is meant for the package maintainer to see if that would fix it the issue.
Comment by Dave Reisner (falconindy) - Wednesday, 09 January 2019, 14:06 GMT
> I suppose the suggestion to revert is meant for the package maintainer to see if that would fix it the issue.

No, it's meant for someone who actually suffers from the issue to revert it and see if it works. Then, if it does work, you can file a bug report upstream. Arch will not be reverting commits in systemd without a clear plan to make changes upstream.
Comment by ipp (n8V8r) - Wednesday, 09 January 2019, 14:17 GMT
How I am supposed to revert that patch without recompiling the package? I reported it here in the fist place because I am using pacman for package maintenance and not compiling packages on my own.

Upstream is apparently aware https://github.com/systemd/systemd/commit/1beab8b0d0#commitcomment-30393464 and thus there is no point in filing another bug report if they do not care.

Well, suppose choices then either to prevent further systemd updates or switch to a distro without systemd.
Comment by Dave Reisner (falconindy) - Wednesday, 09 January 2019, 14:31 GMT
> How I am supposed to revert that patch without recompiling the package? I reported it here in the fist place because I am using pacman for package maintenance and not compiling packages on my own.

How am I, as a maintainer, supposed to help people who report bugs if I can't reproduce the problem on my own? Fixing bugs is a team effort. Arch makes it *extremely* easy to checkout package sources, make modifications, and test those local changes.

> Upstream is apparently aware https://github.com/systemd/systemd/commit/1beab8b0d0#commitcomment-30393464 and thus there is no point in filing another bug report if they do not care.

That link seems to circle back to suggestions that this is problem of LXC and AppArmor. Is this an Arch *host* in addition to an Arch guest?
Comment by ipp (n8V8r) - Wednesday, 09 January 2019, 15:12 GMT
I filed upstream nonetheless https://github.com/systemd/systemd/issues/11371. Let's see to what finger pointing it leads.

The host is ubuntu cosmic but that cannot be the issue since 239.370 in the Arch guest works perfectly fine.

I do not mind the team effort but how is it easy to checkout package sources, make modifications, and test those local changes? I do not want having to install any of these developer/compiler packages and jump to a lot of documentation and other hoops.
Comment by Dave Reisner (falconindy) - Wednesday, 09 January 2019, 15:31 GMT
No, the AA+LXC combination is *exactly* the issue. This isn't something for Arch to fix -- it's a problem of the host, not the guest.
Comment by ipp (n8V8r) - Thursday, 10 January 2019, 13:02 GMT
There are no audit failures recorded by journald which however would be likely if was an issue with AA
Comment by ipp (n8V8r) - Thursday, 10 January 2019, 15:11 GMT
Uhm, my bad (on the host syslog-ng is handling logs and not journald ...) , and on the host indeed

audit: type=1400 audit(1547125168.853:722): apparmor="DENIED" operation="mount" info="failed flags match" error=-13 profile="lxc-container-default-cgns" name="/" pid=8426 comm="(networkd)" flags="rw, rslave"
Comment by ipp (n8V8r) - Thursday, 10 January 2019, 15:32 GMT
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1811248
https://github.com/lxc/lxc/issues/2778

Loading...