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 != &init_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); + I
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
Processed (with 1 error): Re: 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)
Processing control commands: > 908192 blocked by 908223 Unknown command or malformed arguments to command. > tag 908192 + wontfix Bug #908192 [src:linux] linux-image-4.18.0-1-amd64: After upgrade kernel to linux-image-4.18.0-1-amd64, LXC can not start Added tag(s) wontfix. -- 908192: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908192 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed (with 1 error): Re: 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)
Processing control commands: > 908192 blocked by 908223 Unknown command or malformed arguments to command. > tag 908192 + wontfix Bug #908192 [src:linux] linux-image-4.18.0-1-amd64: After upgrade kernel to linux-image-4.18.0-1-amd64, LXC can not start Ignoring request to alter tags of bug #908192 to the same tags previously set -- 908192: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908192 908223: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908223 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
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
Processed: Re: 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)
Processing control commands: > affects -1 + lxc systemd Bug #908192 [src:linux] linux-image-4.18.0-1-amd64: After upgrade kernel to linux-image-4.18.0-1-amd64, LXC can not start Added indication that 908192 affects lxc and systemd -- 908192: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908192 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
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). lxc-s