Bug#908223: Bug#908192: Acknowledgement (linux-image-4.18.0-1-amd64: After upgrade kernel to linux-image-4.18.0-1-amd64, LXC can not start)
On Sat, Oct 13, 2018 at 10:26:57PM +0200, Salvatore Bonaccorso wrote:
> control: 908192 blocked by 908223
> Control: tag 908192 + wontfix
>
> Hi Christian,
>
> On Tue, Oct 09, 2018 at 02:06:09AM +0200, Christian Brauner wrote:
> > On Sat, 22 Sep 2018 21:20:19 +0200 Salvatore Bonaccorso
> > wrote:
> > > Hi,
> > >
> > > On Thu, Sep 20, 2018 at 06:09:07PM +0800, johnw wrote:
> > > >
> > > > Is it also reverted/back port to Debian?
> > > > Because I still have this problem.
> > >
> > > it has not yet been reverted upstream, the discussion got stuck here:
> >
> > Hey, I'm one of the ACKers of the original patch and the author
> > of the revert. The kernel patch that broke userspace won't be reverted
> > upstream.
> > However, I'm also a LXC maintainer and I have fixed LXC upstream to handle
> > 4.18 kernels. The relevant commits are:
> >
> > master:
> > https://github.com/lxc/lxc/commit/3e04a6083eefe0b837db6d1b826721fd985ce052
> > https://github.com/lxc/lxc/commit/5067e4dd8594c3b1f8ee78f0e86edb480f84a156
> >
> > stable-3.0:
> > https://github.com/lxc/lxc/commit/c221e3780a59ac08cd7e8758f7d71422f0c4decf
> >
> > I haven't done a backport of this to stable-2.0 yet. So far there weren't
> > any complains for that one.
>
> Thanks for your followup, much appreciated. The repsective bug report
> for LXC itself is #908223 where it then should be fixed.
Thanks. :)
>
> I'm going to mark #908192 as wontfix for the kernel side. Is it
> planned to backport a fix for stable-2.0?
Just took care of that. I'm appending the commit here but it is
available upstream in the stable-2.0 branch too:
https://github.com/lxc/lxc/commit/db4219603946649474b5cb7915dbd6c17ec728f0
Christian
From db4219603946649474b5cb7915dbd6c17ec728f0 Mon Sep 17 00:00:00 2001
From: Christian Brauner
Date: Sun, 14 Oct 2018 11:42:29 +0200
Subject: [PATCH] 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)
{
/* */
if (s->s_user_ns != _user_ns)
s->s_iflags |= SB_I_NODEV;
/* */
}
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.
This commit enables LXC to deal with such kernels.
Signed-off-by: Christian Brauner
---
src/lxc/conf.c | 116 +
1 file changed, 78 insertions(+), 38 deletions(-)
diff --git a/src/lxc/conf.c b/src/lxc/conf.c
index 09acc34a..e9bed5cb 100644
--- a/src/lxc/conf.c
+++ b/src/lxc/conf.c
@@ -989,6 +989,7 @@ static int mount_autodev(const char *name, const struct lxc_rootfs *rootfs,
int ret;
size_t clen;
char *path;
+ mode_t cur_mask;
INFO("Preparing \"/dev\"");
@@ -1000,37 +1001,45 @@ static int mount_autodev(const char *name, const struct lxc_rootfs *rootfs,
if (ret < 0 || (size_t)ret >= clen)
return -1;
- if (!dir_exists(path)) {
- WARN("\"/dev\" directory does not exist. Proceeding without "
- "autodev being set up");
- return 0;
+ cur_mask = umask(S_IXUSR | S_IXGRP | S_IXOTH);
+ ret = mkdir(path, S_IRWXU | S_IRGRP | S_IXGRP | S_IROTH | S_IXOTH);
+ if (ret < 0 && errno != EEXIST) {
+ SYSERROR("Failed to create \"/dev\" directory");
+ ret = -errno;
+ goto reset_umask;
}
ret = safe_mount("none", path, "tmpfs", 0, "size=50,mode=755",
rootfs->path ? rootfs->mount : NULL);
if (ret < 0) {
SYSERROR("Failed to mount tmpfs on \"%s\"", path);
- return -1;
+ goto reset_umask;
}
- INFO("Mounted tmpfs on \"%s\"", path);
+ TRACE("Mounted tmpfs on \"%s\"", path);
ret = snprintf(path, clen, "%s/dev/pts", rootfs->path ? rootfs->mount : "");
- if (ret < 0 || (size_t)ret >= clen)
- return -1;
+ if (ret < 0 || (size_t)ret >= clen) {
+ ret = -1;
+ goto reset_umask;
+ }
/* If we are running on a devtmpfs mapping, dev/pts may already exist.
* If not, then create it and exit if that fails...
*/
- if (!dir_exists(path)) {
- ret = mkdir(path, S_IRWXU | S_IRGRP | S_IXGRP | S_IROTH | S_IXOTH);
- if (ret < 0) {
- SYSERROR("Failed to create directory \"%s\"", path);
- return -1;
- }
+ ret = mkdir(path, S_IRWXU | S_IRGRP | S_IXGRP | S_IROTH | S_IXOTH);
+ if (ret < 0 && errno != EEXIST) {
+ SYSERROR("Failed to create directory \"%s\"", path);
+ ret = -errno;
+ goto reset_umask;
}
+ ret = 0;
+
+reset_umask:
+ (void)umask(cur_mask);
+
Bug#908192: Acknowledgement (linux-image-4.18.0-1-amd64: After upgrade kernel to linux-image-4.18.0-1-amd64, LXC can not start)
control: 908192 blocked by 908223 Control: tag 908192 + wontfix Hi Christian, On Tue, Oct 09, 2018 at 02:06:09AM +0200, Christian Brauner wrote: > On Sat, 22 Sep 2018 21:20:19 +0200 Salvatore Bonaccorso > wrote: > > Hi, > > > > On Thu, Sep 20, 2018 at 06:09:07PM +0800, johnw wrote: > > > > > > Is it also reverted/back port to Debian? > > > Because I still have this problem. > > > > it has not yet been reverted upstream, the discussion got stuck here: > > Hey, I'm one of the ACKers of the original patch and the author > of the revert. The kernel patch that broke userspace won't be reverted > upstream. > However, I'm also a LXC maintainer and I have fixed LXC upstream to handle > 4.18 kernels. The relevant commits are: > > master: > https://github.com/lxc/lxc/commit/3e04a6083eefe0b837db6d1b826721fd985ce052 > https://github.com/lxc/lxc/commit/5067e4dd8594c3b1f8ee78f0e86edb480f84a156 > > stable-3.0: > https://github.com/lxc/lxc/commit/c221e3780a59ac08cd7e8758f7d71422f0c4decf > > I haven't done a backport of this to stable-2.0 yet. So far there weren't > any complains for that one. Thanks for your followup, much appreciated. The repsective bug report for LXC itself is #908223 where it then should be fixed. I'm going to mark #908192 as wontfix for the kernel side. Is it planned to backport a fix for stable-2.0? Regards, Salvatore
Bug#908192: Acknowledgement (linux-image-4.18.0-1-amd64: After upgrade kernel to linux-image-4.18.0-1-amd64, LXC can not start)
On Sat, 22 Sep 2018 21:20:19 +0200 Salvatore Bonaccorso wrote: > Hi, > > On Thu, Sep 20, 2018 at 06:09:07PM +0800, johnw wrote: > > > > Is it also reverted/back port to Debian? > > Because I still have this problem. > > it has not yet been reverted upstream, the discussion got stuck here: Hey, I'm one of the ACKers of the original patch and the author of the revert. The kernel patch that broke userspace won't be reverted upstream. However, I'm also a LXC maintainer and I have fixed LXC upstream to handle 4.18 kernels. The relevant commits are: master: https://github.com/lxc/lxc/commit/3e04a6083eefe0b837db6d1b826721fd985ce052 https://github.com/lxc/lxc/commit/5067e4dd8594c3b1f8ee78f0e86edb480f84a156 stable-3.0: https://github.com/lxc/lxc/commit/c221e3780a59ac08cd7e8758f7d71422f0c4decf I haven't done a backport of this to stable-2.0 yet. So far there weren't any complains for that one. Christian
Bug#908192: Acknowledgement (linux-image-4.18.0-1-amd64: After upgrade kernel to linux-image-4.18.0-1-amd64, LXC can not start)
Hi, On Thu, Sep 20, 2018 at 06:09:07PM +0800, johnw wrote: > > Is it also reverted/back port to Debian? > Because I still have this problem. it has not yet been reverted upstream, the discussion got stuck here: https://lore.kernel.org/lkml/874lhdwpo2@xmission.com/ Regards, Salvatore
Bug#908192: Acknowledgement (linux-image-4.18.0-1-amd64: After upgrade kernel to linux-image-4.18.0-1-amd64, LXC can not start)
Is it also reverted/back port to Debian? Because I still have this problem. Thanks. On 2018年9月9日 上午3:35:54 [GMT+08:00], Salvatore Bonaccorso < >TTBOMK, the change is beeing discussed to be reverted, >https://lore.kernel.org/lkml/20180705155120.22102-1-christ...@brauner.io/ > >Regards, >Salvatore Key fingerprint: CDB3 6C62 254B C088 1E5D DD32 182C 97DB CF2C 80AC
Bug#908192: Acknowledgement (linux-image-4.18.0-1-amd64: After upgrade kernel to linux-image-4.18.0-1-amd64, LXC can not start)
Control: affects -1 + lxc systemd On Fri, Sep 07, 2018 at 09:54:30PM +0800, johnw wrote: > I can start privileged LXC containers with 4.18 kernel, > Only can not start unprivileged LXC containers with 4.18 kernel. > > Maybe the problem is lxc, not the kernel, > > https://lists.linuxfoundation.org/pipermail/containers/2018-June/039174.html It for instance might affect as well systemd units, which use PrivateDevices=, e.g. see https://github.com/systemd/systemd/pull/9483 . TTBOMK, the change is beeing discussed to be reverted, https://lore.kernel.org/lkml/20180705155120.22102-1-christ...@brauner.io/ Regards, Salvatore
Bug#908192: Acknowledgement (linux-image-4.18.0-1-amd64: After upgrade kernel to linux-image-4.18.0-1-amd64, LXC can not start)
I can start privileged LXC containers with 4.18 kernel, Only can not start unprivileged LXC containers with 4.18 kernel. Maybe the problem is lxc, not the kernel, https://lists.linuxfoundation.org/pipermail/containers/2018-June/039174.html -- Key fingerprint: CDB3 6C62 254B C088 1E5D DD32 182C 97DB CF2C 80AC
Bug#908192: Acknowledgement (linux-image-4.18.0-1-amd64: After upgrade kernel to linux-image-4.18.0-1-amd64, LXC can not start)
Attached config and log file for lxc-start -n name -l debug -- Key fingerprint: CDB3 6C62 254B C088 1E5D DD32 182C 97DB CF2C 80AC lxc.start.auto = 1 lxc.start.delay = 0 # Distribution configuration lxc.include = /usr/share/lxc/config/debian.common.conf lxc.include = /usr/share/lxc/config/debian.userns.conf lxc.arch = x86_64 # Container specific configuration lxc.kmsg = 0 lxc.id_map = u 0 1210 65536 lxc.id_map = g 0 1210 65536 #lxc.cap.drop = sys_module mac_admin mac_override sys_time mknod net_raw sys_rawio sys_nice sys_pacct setfcap setpcap sys_ptrace syslog sys_resource sys_tty_config wake_alarm sys_admin #lxc.aa_profile = lxc-container-default-local #lxc.aa_allow_incomplete = 0 lxc.aa_profile = unconfined lxc.rootfs = /var/lib/lxc/lxc121/rootfs lxc.rootfs.backend = dir lxc.utsname = lxc121 # Network configuration lxc.network.type = veth lxc.network.flags = up lxc.network.link = lxcbr0 lxc.network.hwaddr = AA:BB:CC:DD:01:21 lxc.network.ipv4 = 192.168.168.121/32 lxc.network.ipv4.gateway = 192.168.168.1 # manual mount for drop sys_admin lxc.mount.entry = tmpfs run tmpfs rw,nosuid,noexec,relatime,mode=0755,create=dir 0 0 lxc.mount.entry = tmpfs run/lock tmpfs rw,nosuid,nodev,noexec,relatime,mode=1777,size=5M,create=dir 0 0 lxc.mount.entry = tmpfs run/shm tmpfs rw,nosuid,nodev,noexec,relatime,mode=1777,create=dir 0 0 lxc.mount.entry = tmpfs root tmpfs nosuid,nodev,noatime,mode=0700,uid=0,gid=0 0 0 lxc.mount.entry = tmpfs home/lxc121 tmpfs nosuid,nodev,noatime,mode=0700,uid=1121,gid=1121 0 0 # mount tmp first then GUI lxc.mount.entry = tmpfs tmp tmpfs nosuid,nodev,noatime,mode=1777,create=dir 0 0 lxc.mount.entry = /ramdisk ramdisk none bind,optional,create=dir,nodev,nosuid 0 0 lxc.mount.entry = tmpfs var/cache/apt/archives tmpfs nosuid,nodev,noatime,mode=0755,create=dir 0 0 lxc-start 20180907081437.752 INFO lxc_start_ui - tools/lxc_start.c:main:277 - using rcfile /var/lib/lxc/lxc121/config lxc-start 20180907081437.752 WARN lxc_confile - confile.c:set_config_pivotdir:2262 - lxc.pivotdir is ignored. It will soon become an error. lxc-start 20180907081437.752 INFO lxc_confile - confile.c:set_config_idmaps:1861 - read uid map: type u nsid 0 hostid 1210 range 65536 lxc-start 20180907081437.752 INFO lxc_confile - confile.c:set_config_idmaps:1861 - read uid map: type g nsid 0 hostid 1210 range 65536 lxc-start 20180907081437.752 INFO lxc_container - lxccontainer.c:do_lxcapi_start:877 - Attempting to set proc title to [lxc monitor] /var/lib/lxc lxc121 lxc-start 20180907081437.752 INFO lxc_lsm - lsm/lsm.c:lsm_init:48 - LSM security driver AppArmor lxc-start 20180907081437.753 INFO lxc_seccomp - seccomp.c:parse_config_v2:435 - processing: .reject_force_umount # comment this to allow umount -f; not recommended. lxc-start 20180907081437.753 INFO lxc_seccomp - seccomp.c:parse_config_v2:610 - Adding native rule for reject_force_umount action 0(kill). lxc-start 20180907081437.753 INFO lxc_seccomp - seccomp.c:do_resolve_add_rule:276 - Setting Seccomp rule to reject force umounts. lxc-start 20180907081437.753 INFO lxc_seccomp - seccomp.c:parse_config_v2:614 - Adding compat rule for reject_force_umount action 0(kill). lxc-start 20180907081437.753 INFO lxc_seccomp - seccomp.c:do_resolve_add_rule:276 - Setting Seccomp rule to reject force umounts. lxc-start 20180907081437.753 INFO lxc_seccomp - seccomp.c:do_resolve_add_rule:276 - Setting Seccomp rule to reject force umounts. lxc-start 20180907081437.753 INFO lxc_seccomp - seccomp.c:parse_config_v2:435 - processing: .[all]. lxc-start 20180907081437.753 INFO lxc_seccomp - seccomp.c:parse_config_v2:435 - processing: .kexec_load errno 1. lxc-start 20180907081437.753 INFO lxc_seccomp - seccomp.c:parse_config_v2:610 - Adding native rule for kexec_load action 327681(errno). lxc-start 20180907081437.753 INFO lxc_seccomp - seccomp.c:parse_config_v2:614 - Adding compat rule for kexec_load action 327681(errno). lxc-start 20180907081437.753 INFO lxc_seccomp - seccomp.c:parse_config_v2:435 - processing: .open_by_handle_at errno 1. lxc-start 20180907081437.753 INFO lxc_seccomp - seccomp.c:parse_config_v2:610 - Adding native rule for open_by_handle_at action 327681(errno). lxc-start 20180907081437.753 INFO lxc_seccomp - seccomp.c:parse_config_v2:614 - Adding compat rule for open_by_handle_at action 327681(errno). lxc-start 20180907081437.753 INFO lxc_seccomp - seccomp.c:parse_config_v2:435 - processing: .init_module errno 1. lxc-start 20180907081437.753 INFO lxc_seccomp - seccomp.c:parse_config_v2:610 - Adding native rule for init_module action 327681(errno). lxc-start 20180907081437.753 INFO lxc_seccomp - seccomp.c:parse_config_v2:614 - Adding compat rule for init_module action 327681(errno).
