Hi, upstream git summary: --- begin of quote --- autodev: adapt to changes in Linux 4.18 Starting with commit 55956b59df33 ("vfs: Allow userns root to call mknod on owned filesystems.") Linux will allow mknod() in user namespaces for userns root if CAP_MKNOD is available. However, these device nodes are useless since static struct super_block *alloc_super(struct file_system_type *type, int flags, struct user_namespace *user_ns) { /* <snip> */ if (s->s_user_ns != &init_user_ns) s->s_iflags |= SB_I_NODEV; /* <snip> */ } will set the SB_I_NODEV flag on the filesystem. When a device node created in non-init userns is open()ed the call chain will hit: bool may_open_dev(const struct path *path) { return !(path->mnt->mnt_flags & MNT_NODEV) && !(path->mnt->mnt_sb->s_iflags & SB_I_NODEV); } which will cause an EPERM because the device node is located on an fs owned by non-init-userns and thus doesn't grant access to device nodes due to SB_I_NODEV. The solution is straightforward. Unless you're real root you should bind-mount device nodes. Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com> ---- End of quote --- Patching lxc-3.0.1-r1 went fine on my system, i.e. it LXC builds and LXD can start containers again. Reproducible: Always
Created attachment 543660 [details] lxc-3.0.1-linux-4.18-adoption.patch Linked LXD patch from upstream.
Created attachment 543662 [details] lxc-3.0.1-r2.ebuild Revbumped ebuild: - has some QA/structural changes like a PATCHES=() array - /var/cache is not being created anymore, so it doesn't need to be cleaned - Apparmor is enabled depending on IUSE="apparmor", see bug 657816
Thanks Nils for the patch, but LXC 3.0.2 has been released today and includes this commit. Bumping LXC will make this issue moot. However, since you've already started working on other issues, I'd be glad to let you do the bump and review it. A couple of remarks though: 1. "bug xyz" leftover. 2. You didn't ~all KEYWORDS. Also, it was in my mental "todo list" to address bug 583886 in the next bump. Would you mind doing it?
Thanks Nils, it all looks good except for the removal of /var/cache cleanup. When I build the package, I end up with /var/cache/lxc in my image as well as a QA warning. You don't get this?
(In reply to Virgil Dupras from comment #4) > Thanks Nils, it all looks good except for the removal of /var/cache cleanup. > > When I build the package, I end up with /var/cache/lxc in my image as well > as a QA warning. You don't get this? Hi Virgil, no, I have don’t have them. I ruled out three possible reasons that came to my mind so far: 1. EAPI=7? -> ruled out by bumping lxc-3.0.1-r1 from the main tree to EAPI=7, which would lead to a portage error if rmdir would fail 2. USE="apparmor"? -> ruled out by emerging with USE="-apparmor" 3. toolchain/buildsystem with gcc-8.2-r2, 17.1 profile (with profile migration about a week ago)? -> ruled out because lxc-3.0.1-r1 still emerges fine There is a different warning for the ebuild from the github.com PR though: * One or more empty directories installed to /var: * * /var/lib/cache * /var/lib/cache/lxc * /var/lib/lib * /var/lib/lib/lxc According to 'equery f lxc|grep var' only the following files and directories are actually installed into my root filesystem: /var /var/lib /var/lib/lxc /var/lib/lxc/rootfs /var/lib/lxc/rootfs/.keep_app-emulation_lxc-0 /var/log /var/log/lxc /var/log/lxc/.keep_app-emulation_lxc-0 (Other files in /usr etc. look fine.) Do you have an idea what could cause the different installed paths?
Oh, yes, sorry, /var/cache became /var/lib/cache and rmdir caused errors. I have the same result as you (with the weird /var/lib/lib/lxc as well. this desn't sound right...) Still, it's not the proper fix to remove this "rmdir" call. We have to find out why these paths changed. Looking into it.
Got it: I diffed the "config.status" of both lxc-3.0.1-r1 and lxc-3.0.2. It goes from "/var" to "/var/lib". In both cases, there is a "--localstatedir=/var/lib" being passed, but in 3.0.1-r1, it's being overridden by our "--localstatedir=/var" from src_configure() In fact, none of the arguments are passed. It seems that your conversion to an array is broken.
(In reply to Virgil Dupras from comment #7) > Got it: I diffed the "config.status" of both lxc-3.0.1-r1 and lxc-3.0.2. It > goes from "/var" to "/var/lib". In both cases, there is a > "--localstatedir=/var/lib" being passed, but in 3.0.1-r1, it's being > overridden by our "--localstatedir=/var" from src_configure() > > In fact, none of the arguments are passed. It seems that your conversion to > an array is broken. Thanks, I had a typo (myeconfargs vs my_econfargs) which now is fixed and pushed.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=f63fbe792e3f4db205f04df2376a5aa0f92de494 commit f63fbe792e3f4db205f04df2376a5aa0f92de494 Author: Nils Freydank <holgersson@posteo.de> AuthorDate: 2018-08-21 21:45:23 +0000 Commit: Virgil Dupras <vdupras@gentoo.org> CommitDate: 2018-08-22 12:24:57 +0000 app-emulation/lxc: Bump to 3.0.2. Closes: https://bugs.gentoo.org/583886 Closes: https://bugs.gentoo.org/657816 Closes: https://bugs.gentoo.org/663780 Package-Manager: Portage-2.3.48, Repoman-2.3.10 Closes: https://github.com/gentoo/gentoo/pull/9651 app-emulation/lxc/Manifest | 1 + app-emulation/lxc/lxc-3.0.2.ebuild | 158 +++++++++++++++++++++++++++++++++++++ app-emulation/lxc/metadata.xml | 1 + 3 files changed, 160 insertions(+)
