FS#61808 - {arch-install-scripts} bind mount of /run causes systemd-tmpfiles to mess up uids in host /run
Attached to Project:
Arch Linux
Opened by Axel Hinrichs (ahinrichs) - Tuesday, 19 February 2019, 13:54 GMT
Last edited by Morten Linderud (Foxboron) - Sunday, 03 July 2022, 12:50 GMT
Opened by Axel Hinrichs (ahinrichs) - Tuesday, 19 February 2019, 13:54 GMT
Last edited by Morten Linderud (Foxboron) - Sunday, 03 July 2022, 12:50 GMT
|
Details
Description: pacstrap bind mounts host /run into chroot dir.
If you install systemd in chroot the post install hook
systemd-tmpfiles.hook is run with the chroot /etc/passd but
host /run. On my host the uid of systemd-network differes
from the new chroot and so /run/systemd/netif gets messed
up.
Additional info: * commit https://git.archlinux.org/arch-install-scripts.git/commit/?id=aea51ba9012ace489d10543f34ebea9c5aebd812 changed to bind mount the host dir /run in $newroot * intention was to fix https://bugs.archlinux.org/task/61040 Steps to reproduce: # ls -la /run/systemd/ [...] drwxr-xr-x 5 systemd-network systemd-network 120 Feb 19 14:09 netif [...] # mkdir /tmp/chroot # pacstrap -c /tmp/chroot systemd # ls -la /run/systemd/ [...] drwxr-xr-x 5 981 981 120 Feb 19 14:23 netif [...] |
This task depends upon
Closed by Morten Linderud (Foxboron)
Sunday, 03 July 2022, 12:50 GMT
Reason for closing: Fixed
Additional comments about closing: 25-1
Sunday, 03 July 2022, 12:50 GMT
Reason for closing: Fixed
Additional comments about closing: 25-1
I don't think the pacstrap run should have side effects on the hosts /run tree. In my case the effect was, that the host /run/systemd/netif({links/lease} folders weren't writable by the systemd-networkd anymore flooding log with "access denied". But I could think of any kind of problems.
$newroot/run used to be an empty tmpfs. To fix the
bug 61040the chroot lvm install scripts should be able to talk to the running lvm sockets /run/lvm/lvmetad.socket. For that they bind mount the whole /run folder into $newroot. But any package script of the pacstrap run now operates on the host /run folder which I don't think is intended.I could think of making $newroot/run again an empty tmpfs and just bind mount /run/lvm on $newroot/run/lvm. Or to fix the other side /usr/share/libalpm/scripts/systemd-hook should check systemd_live before "tmpfiles --create" too.
FS#61040could then be reverted.When bind mounting /run, a docker daemon from host is somehow using $chroot/run/docker/netns/* as mount targets and pacstrap seems to fail (silently) on unmounting $chroot/run because of it.
I might be hitting a similar issue to this: https://github.com/weaveworks/weave/issues/1455
Patching pacstrap and arch-chroot to mount $chroot/run as tmpfs fix this for me.
FS#61040does that reintroduce that issue?If
FS#61040is still an issue, is there an alternative solution that can be applied to grub?Or what if $chroot/run is made a tmpfs again with /run/lvm being bind mounted to $chroot/run/lvm within it?
then yes, this is basically what I've done.
I don't use lvm so I don't know if the change ends with a regression for lvm users.
But the current behavior is also not unacceptable and it unexpectedly took down my X session as my Xauthority is set to $XDG_RUNTIME_DIR"/Xauthority.
Initially, I also made the mistake of deleting $chroot/run, thinking pacstrap unmounted everything correctly, and that ended with needing to use SysRq in order to reboot.
If you build arch-install-scripts with the applied patch does arch-chroot work as expected on your system?
FS#61040than the first fix. (TBH: I did not fully build the package for testing the patch but applied it by hand to arch-chroot)For example, samba did this, packaging `/run/samba`, thankfully it was fixed, and my bug report wasn't ignored like the autofs one which I believe is still packaging `/run`, now in the AUR.
P.S. What I think does not really matter though. At the end of the day it's really just a matter of who's maintaining / who has the right to maintain it, and some Arch dev(s) (well, or just people in general) are known to have their own worldview on what's right or wrong / good or bad, without needing a rationale or proof to support it. (Luckily, it's just a script anyway.)
So you suggest a fix and then don't care about testing if it diverges from current behavior?
>Often "showing" what is wrong / broken is the only way to get people motivated in fixing it
I have bug reports about packaging issues that have been ignored for over a year without any response from the package maintainer, even when suggesting a fix, sometimes as an attached patch.
I think that you shouldn't create a problem that didn't exist and throw this at package maintainers.
> ... are known to have their own worldview on what's right or wrong / good or bad, without needing a rationale or proof to support it.
That's call religion, and I hope that's not a factor in software development related decisions.
The bind mount was introduced to mitigate an issue with lvm. I's been a tmpfs long time before. The proposed fix perfectly handles the /run/lvm and protects the host /run otherwise like it was before. I can't find any reason not to include this patch.
I mean I don't care if there will be hiccup when a package that consists of files in /run makes no sense given that we assume /run to have a tmpfs mounted on it. In other words, IMHO we should fix wrong-doing that prevents us from doing a right thing instead of avoiding doing the right thing because there have been some wrong-doing.
I wonder why reverting this breaking change and redo it more specific to the reasoning is such a big deal. /chroot/run used to be a tmpfs ever before. It was not changed because that tmpfs was a problem. It's been changed to a bind mound because the lvm package somehow tried to access /run/lvm. And the test.patch does exactly the right thing. Keep (or make again) /chroot/run a tmpfs and just bind mount /run/lvm to /chroot/run/lvm.
No one (at least not me) wants to keep you server "dead". It's just neither is my focus getting your server or some other scenario "work". Getting things work (for some) ASAP is not and will never be my concern, because you can easily get it work for you with /usr/local/bin. Doing it right, whether there's a real (like technical or logical) reason to merely "revert and make exception" is my only concern (I didn't rule out that the need of not bind mounting btw. See the last paragraph of my PR's message. Bare in mind "need" does not refer to what can be and should be fixed though.)
But again, what I think doesn't matter. I just couldn't help when being addressed, sort of.
[1] https://github.com/archlinux/arch-install-scripts/commit/8a5613392686a0f07d8664eecb78895b12bfb3e7