[Kernel-packages] [Bug 1998602] Re: overlay writing user.* xattrs on symlinks
> I had thought I should be able to reproduce it by mounting (in an unprivileged user+mountns) an overlayfs where the underlay has, say, "/etc/rc2.d/K" symlink, then rename K to S (as i assume the 'systemctl disable dnsmasq is doing), but that did not work for me. Fwiw, I think you need index=on enabled for origin xattrs to be set. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1998602 Title: overlay writing user.* xattrs on symlinks Status in linux package in Ubuntu: Incomplete Bug description: This was reported (and worked around) in https://github.com/project- stacker/stacker/pull/333. The kernel does not allow user.* xattrs on a symlink. However, on 5.15.0-53-generic and 5.19.0-21-generic, but not on the ubuntu mainline build (6.1.0-060100rc5-generic), an unprivileged program can cause such xattrs to be created. Once they're there, userspace (i.e. setfattr) cannot remove them since the kernel says they can't exist - but listxattr shows them. I've failed so far in setting up a simpler reproducer, so I'll begin by reporting the full reproducer. Download 'stacker' from https://github.com/project- stacker/stacker/releases/download/v0.22.1/stacker . Create a stacker.yaml config file: cat > stacker.yaml << EOF pxe-server-base: from: type: docker url: docker://ubuntu:jammy run: | apt-get update apt-get -y install dnsmasq systemd sb-pxe-server: from: type: built tag: pxe-server-base run: | systemctl disable dnsmasq EOF and run 'stacker build'. It will end with: Executing: /lib/systemd/systemd-sysv-install disable dnsmasq Removed /etc/systemd/system/multi-user.target.wants/dnsmasq.service. error: /home/ubuntu/build2/roots/sb-pxe-server/overlay/etc/rc2.d/K01dnsmasq: failed to remove attr user.overlay.origin: xattr.LRemove /home/ubuntu/build2/roots/sb-pxe-server/overlay/etc/rc2.d/K01dnsmasq user.overlay.origin: operation not permitted error: exit status 1 You'll subsequently see that ./roots/sb-pxe- server/overlay/etc/rc2.d/K01dnsmasq is a symbolic link with user.overlay.origin xattr (per llistxatr), though you can't read the contents or delete it. I had thought I should be able to reproduce it by mounting (in an unprivileged user+mountns) an overlayfs where the underlay has, say, "/etc/rc2.d/K" symlink, then rename K to S (as i assume the 'systemctl disable dnsmasq is doing), but that did not work for me. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1998602/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1940392] Re: fs: removing mandatory locks
** Changed in: linux (Ubuntu) Status: Incomplete => Confirmed -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1940392 Title: fs: removing mandatory locks Status in linux package in Ubuntu: Confirmed Bug description: Hello, Upstream is dicussing the removal of mandatory locks. To actually do this at some point distros will need to start disabling CONFIG_MANDATORY_FILE_LOCKING. It seems our kernel still defaults to CONFIG_MANDATORY_FILE_LOCKING=y. If feasible I'd like to propose disabling CONFIG_MANDATORY_FILE_LOCKING in the upcoming kernel releases. From the thread it seems that RHEL 8 and Fedora already disable mandatory locks: https://lore.kernel.org/lkml/c65c4e42-9661-1321-eaf8-61b1d6f89...@redhat.com Thanks! Christian To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1940392/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1940392] [NEW] fs: removing mandatory locks
Public bug reported: Hello, Upstream is dicussing the removal of mandatory locks. To actually do this at some point distros will need to start disabling CONFIG_MANDATORY_FILE_LOCKING. It seems our kernel still defaults to CONFIG_MANDATORY_FILE_LOCKING=y. If feasible I'd like to propose disabling CONFIG_MANDATORY_FILE_LOCKING in the upcoming kernel releases. >From the thread it seems that RHEL 8 and Fedora already disable mandatory locks: https://lore.kernel.org/lkml/c65c4e42-9661-1321-eaf8-61b1d6f89...@redhat.com Thanks! Christian ** Affects: linux (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1940392 Title: fs: removing mandatory locks Status in linux package in Ubuntu: New Bug description: Hello, Upstream is dicussing the removal of mandatory locks. To actually do this at some point distros will need to start disabling CONFIG_MANDATORY_FILE_LOCKING. It seems our kernel still defaults to CONFIG_MANDATORY_FILE_LOCKING=y. If feasible I'd like to propose disabling CONFIG_MANDATORY_FILE_LOCKING in the upcoming kernel releases. From the thread it seems that RHEL 8 and Fedora already disable mandatory locks: https://lore.kernel.org/lkml/c65c4e42-9661-1321-eaf8-61b1d6f89...@redhat.com Thanks! Christian To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1940392/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1939301] Re: REGRESSION: shiftfs lets sendfile fail with EINVAL
** Changed in: linux-meta-hwe-5.11 (Ubuntu)
Status: New => Confirmed
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-meta-hwe-5.11 in Ubuntu.
https://bugs.launchpad.net/bugs/1939301
Title:
REGRESSION: shiftfs lets sendfile fail with EINVAL
Status in linux-meta-hwe-5.11 package in Ubuntu:
Confirmed
Bug description:
With the 5.11 HWE kernel landing for Ubuntu 20.04 we noticed that LXC
tools we're using in bionic containers as part of Anbox Cloud start to
fail when executed on the 5.11 kernel.
A simple reproducer looks like this:
1. Run Ubuntu 20.04 with HWE kernel (linux-generic-hwe-20.04,
5.11.0-25-generic #27~20.04.1-Ubuntu)
2. Install LXD and enable shiftfs
$ snap install lxd
$ snap set lxd shiftfs.enable true
$ snap restart --reload lxd
3. Launch bionic container and run `lxc-info`
$ lxc launch ubuntu:b c0
$ lxc shell c0
c0$ apt update
c0$ apt install -y lxc-utils
root@c1:~# apt show lxc-utils | grep Version
Version: 3.0.3-0ubuntu1~18.04.1
c0$ mkdir -p containers/test
c0$ touch containers/test/config
c0$ lxc-info -P containers -n test
Failed to load config for test
Failure to retrieve information on containers:test
Looking into the failing `lxc-info` call with strace reveals:
...
memfd_create(".lxc_config_file", MFD_CLOEXEC) = 4
openat(AT_FDCWD, "containers/test/config", O_RDONLY|O_CLOEXEC) = 5
sendfile(4, 5, NULL, 2147479552)= -1 EINVAL (Invalid argument
...
LXC >= 4.0.0 doesn't use sendfile anymore and with that isn't
affected. Any other tool using sendfile however is affected and will
fail. Bionic is affected as the 3.0.3 version of LXC it includes still
uses sendfile.
Disabling shiftfs makes things work again and can be considered as a
workaround to a certain degree, but not be applicable in all cases.
Further analysis with Christian (cbrauner) from the LXD team this
morning showed that shiftfs is missing an implementation for the now
required slice_read handler in the file_operations structure. So
whenever shiftfs is being used, all calls to sendfile will fail
because of the missing implementation. The generic handler for this
got removed in the following upstream change:
https://lore.kernel.org/lkml/20200626075836.1998185-10-...@lst.de/
Christian implemented a quick fix:
https://paste.ubuntu.com/p/TPsjfCpnD5/
As of today I don't know of any customer of Anbox Cloud who is
affected by this as most of them run with one of our cloud kernels.
However as soon as 5.11 rolls out to the cloud kernels, we will hit
production systems and cause them to fail.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux-meta-hwe-5.11/+bug/1939301/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1908225] [NEW] iwd triggers WARN in net/wireless/nl80221.c
Public bug reported: On Linux wittgenstein 5.8.0-33-generic #36-Ubuntu SMP Wed Dec 9 09:14:40 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux Distributor ID: Ubuntu Description:Ubuntu 20.10 Release:20.10 Codename: groovy iwd manages to trigger the following warn: [ 47.003606] NET: Registered protocol family 38 [ 47.306287] [ cut here ] [ 47.306318] WARNING: CPU: 1 PID: 1143 at net/wireless/nl80211.c:7288 nl80211_get_reg_do+0x1fc/0x230 [cfg80211] [ 47.306318] Modules linked in: ccm algif_aead des_generic libdes arc4 algif_skcipher cmac md4 algif_hash af_alg binfmt_misc zfs(PO) zunicode(PO) zavl(PO) icp(PO) nls_iso8859_1 zcommon(PO) znvpair(PO) spl(O) zlua(PO) snd_hda_codec_hdmi x86_pkg_temp_thermal snd_hda_codec_realtek intel_powerclamp snd_hda_codec_generic coretemp snd_hda_intel iwlmvm snd_intel_dspcfg mac80211 snd_hda_codec kvm_intel typec_displayport snd_hda_core kvm snd_hwdep snd_pcm joydev mei_hdcp libarc4 thinkpad_acpi nvram intel_rapl_msr ledtrig_audio snd_seq_midi rapl snd_seq_midi_event snd_rawmidi intel_cstate input_leds serio_raw uvcvideo snd_seq efi_pstore iwlwifi rmi_smbus btusb rmi_core btrtl snd_seq_device btbcm snd_timer videobuf2_vmalloc btintel videobuf2_memops videobuf2_v4l2 bluetooth videobuf2_common snd wmi_bmof intel_wmi_thunderbolt videodev ucsi_acpi cfg80211 processor_thermal_device typec_ucsi intel_xhci_usb_role_switch mc roles ecdh_generic int3400_thermal typec mac_hid soundcore ecc mei_me int3403_thermal [ 47.306348] intel_rapl_common acpi_thermal_rel acpi_pad int340x_thermal_zone mei intel_soc_dts_iosf intel_pch_thermal sch_fq_codel pkcs8_key_parser ip_tables x_tables autofs4 btrfs blake2b_generic xor raid6_pq libcrc32c dm_crypt uas usb_storage i915 i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops cec crct10dif_pclmul crc32_pclmul ghash_clmulni_intel rc_core aesni_intel crypto_simd cryptd nvme glue_helper psmouse e1000e drm thunderbolt i2c_i801 xhci_pci i2c_smbus nvme_core xhci_pci_renesas wmi i2c_hid hid video [ 47.306369] CPU: 1 PID: 1143 Comm: iwd Tainted: P U O 5.8.0-33-generic #36-Ubuntu [ 47.306369] Hardware name: LENOVO 20KHCTO1WW/20KHCTO1WW, BIOS N23ET75W (1.50 ) 10/13/2020 [ 47.306392] RIP: 0010:nl80211_get_reg_do+0x1fc/0x230 [cfg80211] [ 47.306394] Code: 45 cc 01 00 00 00 e8 83 b6 70 ee 85 c0 0f 84 fd fe ff ff eb a8 4c 89 e7 48 89 45 c0 e8 dd ae b1 ee 48 8b 45 c0 e9 40 ff ff ff <0f> 0b 4c 89 e7 e8 ca ae b1 ee b8 ea ff ff ff e9 2c ff ff ff e9 7a [ 47.306395] RSP: 0018:ab21009d7b70 EFLAGS: 00010202 [ 47.306396] RAX: RBX: 0001 RCX: [ 47.306397] RDX: 98077b560008 RSI: RDI: 98077b5602e0 [ 47.306398] RBP: ab21009d7bb0 R08: 98077b5602e0 R09: 98078597b014 [ 47.306399] R10: R11: 001f R12: 98077d78a100 [ 47.306400] R13: ab21009d7bd0 R14: 98078597b014 R15: [ 47.306402] FS: 7fa3cbea0740() GS:98079164() knlGS: [ 47.306403] CS: 0010 DS: ES: CR0: 80050033 [ 47.306404] CR2: 7ffd949e7c40 CR3: 00048596c004 CR4: 003606e0 [ 47.306404] DR0: DR1: DR2: [ 47.306405] DR3: DR6: fffe0ff0 DR7: 0400 [ 47.306406] Call Trace: [ 47.306413] ? rtnl_lock+0x15/0x20 [ 47.306417] genl_family_rcv_msg+0x17b/0x290 [ 47.306420] genl_rcv_msg+0x4c/0xa0 [ 47.306421] ? genl_family_rcv_msg+0x290/0x290 [ 47.306423] netlink_rcv_skb+0x4e/0x110 [ 47.306425] genl_rcv+0x29/0x40 [ 47.306427] netlink_unicast+0x218/0x330 [ 47.306429] netlink_sendmsg+0x23b/0x460 [ 47.306431] ? aa_sk_perm+0x43/0x1b0 [ 47.306434] sock_sendmsg+0x65/0x70 [ 47.306435] __sys_sendto+0x113/0x190 [ 47.306439] ? __secure_computing+0x42/0xe0 [ 47.306442] ? syscall_trace_enter+0xaf/0x270 [ 47.306475] __x64_sys_sendto+0x29/0x30 [ 47.306478] do_syscall_64+0x49/0xc0 [ 47.306480] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 47.306481] RIP: 0033:0x7fa3cbfbd6c0 [ 47.306483] Code: c0 ff ff ff ff eb b8 0f 1f 00 f3 0f 1e fa 41 89 ca 64 8b 04 25 18 00 00 00 85 c0 75 1d 45 31 c9 45 31 c0 b8 2c 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 68 c3 0f 1f 80 00 00 00 00 55 48 83 ec 20 48 [ 47.306484] RSP: 002b:7ffd949ec2f8 EFLAGS: 0246 ORIG_RAX: 002c [ 47.306485] RAX: ffda RBX: 5640b5603b00 RCX: 7fa3cbfbd6c0 [ 47.306486] RDX: 001c RSI: 5640b560eff0 RDI: 0004 [ 47.306486] RBP: 5640b560e8e0 R08: R09: [ 47.306487] R10: R11: 0246 R12: 7ffd949ec35c [ 47.306488] R13: 7ffd949ec358 R14: 5640b560d790 R15: [ 47.306490] ---[ end trace 4bb70ad9a9020389 ]--- This is located in: static int nl80211_get_reg_do(struct
[Kernel-packages] [Bug 1908227] Re: iwd triggers WARN in net/wireless/nl80221.c
> ip addr 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: enp0s31f6: mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether 8c:16:45:e0:3b:f5 brd ff:ff:ff:ff:ff:ff 4: wlan0: mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether 3c:6a:a7:16:8c:cb brd ff:ff:ff:ff:ff:ff inet 192.168.178.21/24 brd 192.168.178.255 scope global wlan0 valid_lft forever preferred_lft forever inet6 fd00::2103:753d:5063:ec5e/64 scope global temporary dynamic valid_lft 6647sec preferred_lft 3047sec inet6 fd00::3e6a:a7ff:fe16:8ccb/64 scope global dynamic mngtmpaddr valid_lft 6647sec preferred_lft 3047sec inet6 fe80::3e6a:a7ff:fe16:8ccb/64 scope link valid_lft forever preferred_lft forever 5: lxcbr0: mtu 1500 qdisc noqueue state DOWN group default qlen 1000 link/ether 00:16:3e:00:00:00 brd ff:ff:ff:ff:ff:ff inet 10.0.3.1/24 brd 10.0.3.255 scope global lxcbr0 valid_lft forever preferred_lft forever -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1908227 Title: iwd triggers WARN in net/wireless/nl80221.c Status in linux package in Ubuntu: New Bug description: On Linux wittgenstein 5.8.0-33-generic #36-Ubuntu SMP Wed Dec 9 09:14:40 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux Distributor ID: Ubuntu Description: Ubuntu 20.10 Release: 20.10 Codename: groovy iwd manages to trigger the following warn: [ 47.003606] NET: Registered protocol family 38 [ 47.306287] [ cut here ] [ 47.306318] WARNING: CPU: 1 PID: 1143 at net/wireless/nl80211.c:7288 nl80211_get_reg_do+0x1fc/0x230 [cfg80211] [ 47.306318] Modules linked in: ccm algif_aead des_generic libdes arc4 algif_skcipher cmac md4 algif_hash af_alg binfmt_misc zfs(PO) zunicode(PO) zavl(PO) icp(PO) nls_iso8859_1 zcommon(PO) znvpair(PO) spl(O) zlua(PO) snd_hda_codec_hdmi x86_pkg_temp_thermal snd_hda_codec_realtek intel_powerclamp snd_hda_codec_generic coretemp snd_hda_intel iwlmvm snd_intel_dspcfg mac80211 snd_hda_codec kvm_intel typec_displayport snd_hda_core kvm snd_hwdep snd_pcm joydev mei_hdcp libarc4 thinkpad_acpi nvram intel_rapl_msr ledtrig_audio snd_seq_midi rapl snd_seq_midi_event snd_rawmidi intel_cstate input_leds serio_raw uvcvideo snd_seq efi_pstore iwlwifi rmi_smbus btusb rmi_core btrtl snd_seq_device btbcm snd_timer videobuf2_vmalloc btintel videobuf2_memops videobuf2_v4l2 bluetooth videobuf2_common snd wmi_bmof intel_wmi_thunderbolt videodev ucsi_acpi cfg80211 processor_thermal_device typec_ucsi intel_xhci_usb_role_switch mc roles ecdh_generic int3400_thermal typec mac_hid soundcore ecc mei_me int3403_thermal [ 47.306348] intel_rapl_common acpi_thermal_rel acpi_pad int340x_thermal_zone mei intel_soc_dts_iosf intel_pch_thermal sch_fq_codel pkcs8_key_parser ip_tables x_tables autofs4 btrfs blake2b_generic xor raid6_pq libcrc32c dm_crypt uas usb_storage i915 i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops cec crct10dif_pclmul crc32_pclmul ghash_clmulni_intel rc_core aesni_intel crypto_simd cryptd nvme glue_helper psmouse e1000e drm thunderbolt i2c_i801 xhci_pci i2c_smbus nvme_core xhci_pci_renesas wmi i2c_hid hid video [ 47.306369] CPU: 1 PID: 1143 Comm: iwd Tainted: P U O 5.8.0-33-generic #36-Ubuntu [ 47.306369] Hardware name: LENOVO 20KHCTO1WW/20KHCTO1WW, BIOS N23ET75W (1.50 ) 10/13/2020 [ 47.306392] RIP: 0010:nl80211_get_reg_do+0x1fc/0x230 [cfg80211] [ 47.306394] Code: 45 cc 01 00 00 00 e8 83 b6 70 ee 85 c0 0f 84 fd fe ff ff eb a8 4c 89 e7 48 89 45 c0 e8 dd ae b1 ee 48 8b 45 c0 e9 40 ff ff ff <0f> 0b 4c 89 e7 e8 ca ae b1 ee b8 ea ff ff ff e9 2c ff ff ff e9 7a [ 47.306395] RSP: 0018:ab21009d7b70 EFLAGS: 00010202 [ 47.306396] RAX: RBX: 0001 RCX: [ 47.306397] RDX: 98077b560008 RSI: RDI: 98077b5602e0 [ 47.306398] RBP: ab21009d7bb0 R08: 98077b5602e0 R09: 98078597b014 [ 47.306399] R10: R11: 001f R12: 98077d78a100 [ 47.306400] R13: ab21009d7bd0 R14: 98078597b014 R15: [ 47.306402] FS: 7fa3cbea0740() GS:98079164() knlGS: [ 47.306403] CS: 0010 DS: ES: CR0: 80050033 [ 47.306404] CR2: 7ffd949e7c40 CR3: 00048596c004 CR4: 003606e0 [ 47.306404] DR0: DR1: DR2: [ 47.306405] DR3: DR6: fffe0ff0 DR7: 0400 [ 47.306406] Call Trace: [
[Kernel-packages] [Bug 1908227] [NEW] iwd triggers WARN in net/wireless/nl80221.c
Public bug reported: On Linux wittgenstein 5.8.0-33-generic #36-Ubuntu SMP Wed Dec 9 09:14:40 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux Distributor ID: Ubuntu Description:Ubuntu 20.10 Release:20.10 Codename: groovy iwd manages to trigger the following warn: [ 47.003606] NET: Registered protocol family 38 [ 47.306287] [ cut here ] [ 47.306318] WARNING: CPU: 1 PID: 1143 at net/wireless/nl80211.c:7288 nl80211_get_reg_do+0x1fc/0x230 [cfg80211] [ 47.306318] Modules linked in: ccm algif_aead des_generic libdes arc4 algif_skcipher cmac md4 algif_hash af_alg binfmt_misc zfs(PO) zunicode(PO) zavl(PO) icp(PO) nls_iso8859_1 zcommon(PO) znvpair(PO) spl(O) zlua(PO) snd_hda_codec_hdmi x86_pkg_temp_thermal snd_hda_codec_realtek intel_powerclamp snd_hda_codec_generic coretemp snd_hda_intel iwlmvm snd_intel_dspcfg mac80211 snd_hda_codec kvm_intel typec_displayport snd_hda_core kvm snd_hwdep snd_pcm joydev mei_hdcp libarc4 thinkpad_acpi nvram intel_rapl_msr ledtrig_audio snd_seq_midi rapl snd_seq_midi_event snd_rawmidi intel_cstate input_leds serio_raw uvcvideo snd_seq efi_pstore iwlwifi rmi_smbus btusb rmi_core btrtl snd_seq_device btbcm snd_timer videobuf2_vmalloc btintel videobuf2_memops videobuf2_v4l2 bluetooth videobuf2_common snd wmi_bmof intel_wmi_thunderbolt videodev ucsi_acpi cfg80211 processor_thermal_device typec_ucsi intel_xhci_usb_role_switch mc roles ecdh_generic int3400_thermal typec mac_hid soundcore ecc mei_me int3403_thermal [ 47.306348] intel_rapl_common acpi_thermal_rel acpi_pad int340x_thermal_zone mei intel_soc_dts_iosf intel_pch_thermal sch_fq_codel pkcs8_key_parser ip_tables x_tables autofs4 btrfs blake2b_generic xor raid6_pq libcrc32c dm_crypt uas usb_storage i915 i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops cec crct10dif_pclmul crc32_pclmul ghash_clmulni_intel rc_core aesni_intel crypto_simd cryptd nvme glue_helper psmouse e1000e drm thunderbolt i2c_i801 xhci_pci i2c_smbus nvme_core xhci_pci_renesas wmi i2c_hid hid video [ 47.306369] CPU: 1 PID: 1143 Comm: iwd Tainted: P U O 5.8.0-33-generic #36-Ubuntu [ 47.306369] Hardware name: LENOVO 20KHCTO1WW/20KHCTO1WW, BIOS N23ET75W (1.50 ) 10/13/2020 [ 47.306392] RIP: 0010:nl80211_get_reg_do+0x1fc/0x230 [cfg80211] [ 47.306394] Code: 45 cc 01 00 00 00 e8 83 b6 70 ee 85 c0 0f 84 fd fe ff ff eb a8 4c 89 e7 48 89 45 c0 e8 dd ae b1 ee 48 8b 45 c0 e9 40 ff ff ff <0f> 0b 4c 89 e7 e8 ca ae b1 ee b8 ea ff ff ff e9 2c ff ff ff e9 7a [ 47.306395] RSP: 0018:ab21009d7b70 EFLAGS: 00010202 [ 47.306396] RAX: RBX: 0001 RCX: [ 47.306397] RDX: 98077b560008 RSI: RDI: 98077b5602e0 [ 47.306398] RBP: ab21009d7bb0 R08: 98077b5602e0 R09: 98078597b014 [ 47.306399] R10: R11: 001f R12: 98077d78a100 [ 47.306400] R13: ab21009d7bd0 R14: 98078597b014 R15: [ 47.306402] FS: 7fa3cbea0740() GS:98079164() knlGS: [ 47.306403] CS: 0010 DS: ES: CR0: 80050033 [ 47.306404] CR2: 7ffd949e7c40 CR3: 00048596c004 CR4: 003606e0 [ 47.306404] DR0: DR1: DR2: [ 47.306405] DR3: DR6: fffe0ff0 DR7: 0400 [ 47.306406] Call Trace: [ 47.306413] ? rtnl_lock+0x15/0x20 [ 47.306417] genl_family_rcv_msg+0x17b/0x290 [ 47.306420] genl_rcv_msg+0x4c/0xa0 [ 47.306421] ? genl_family_rcv_msg+0x290/0x290 [ 47.306423] netlink_rcv_skb+0x4e/0x110 [ 47.306425] genl_rcv+0x29/0x40 [ 47.306427] netlink_unicast+0x218/0x330 [ 47.306429] netlink_sendmsg+0x23b/0x460 [ 47.306431] ? aa_sk_perm+0x43/0x1b0 [ 47.306434] sock_sendmsg+0x65/0x70 [ 47.306435] __sys_sendto+0x113/0x190 [ 47.306439] ? __secure_computing+0x42/0xe0 [ 47.306442] ? syscall_trace_enter+0xaf/0x270 [ 47.306475] __x64_sys_sendto+0x29/0x30 [ 47.306478] do_syscall_64+0x49/0xc0 [ 47.306480] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 47.306481] RIP: 0033:0x7fa3cbfbd6c0 [ 47.306483] Code: c0 ff ff ff ff eb b8 0f 1f 00 f3 0f 1e fa 41 89 ca 64 8b 04 25 18 00 00 00 85 c0 75 1d 45 31 c9 45 31 c0 b8 2c 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 68 c3 0f 1f 80 00 00 00 00 55 48 83 ec 20 48 [ 47.306484] RSP: 002b:7ffd949ec2f8 EFLAGS: 0246 ORIG_RAX: 002c [ 47.306485] RAX: ffda RBX: 5640b5603b00 RCX: 7fa3cbfbd6c0 [ 47.306486] RDX: 001c RSI: 5640b560eff0 RDI: 0004 [ 47.306486] RBP: 5640b560e8e0 R08: R09: [ 47.306487] R10: R11: 0246 R12: 7ffd949ec35c [ 47.306488] R13: 7ffd949ec358 R14: 5640b560d790 R15: [ 47.306490] ---[ end trace 4bb70ad9a9020389 ]--- This is located in: static int nl80211_get_reg_do(struct
[Kernel-packages] [Bug 1895132] Re: s390x broken with unknown syscall number on kernels < 5.8
This needs to be backported to our 5.4 kernels.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1895132
Title:
s390x broken with unknown syscall number on kernels < 5.8
Status in linux package in Ubuntu:
Confirmed
Bug description:
SRU Justification
Impact: On kernels prior to 5.8 when a task is in traced state (due to
audit, ptrace, or seccomp) s390x and a syscall is issued that the
kernel doesn't know about s390x will not return ENOSYS in r2 but
instead will return the syscall number. This breaks userspace all over
the place. The following program compiled on s390x will output 500
instead of -ENOSYS:
root@test:~# cat test.c
#define _GNU_SOURCE
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
static inline int dummy_inline_asm(void)
{
register long r1 asm("r1") = 500;
register long r2 asm("r2") = -1;
register long r3 asm("r3") = -1;
register long r4 asm("r4") = -1;
register long r5 asm("r5") = -1;
register long __res_r2 asm("r2");
asm volatile(
"svc 0\n\t"
: "=d"(__res_r2)
: "d"(r1), "0"(r2), "d"(r3), "d"(r4), "d"(r5)
: "memory");
return (int) __res_r2;
}
static inline int dummy_syscall(void)
{
return syscall(500, -1, -1, -1, -1);
}
int main(int argc, char *argv[])
{
printf("Uhm: %d\n", dummy_inline_asm());
printf("Uhm: %d\n", dummy_syscall());
exit(EXIT_SUCCESS);
}
This breaks LXD on s390x currently completely as well as strace.
Fix: Backport
commit cd29fa798001075a554b978df3a64e6656c25794
Author: Sven Schnelle
Date: Fri Mar 6 13:18:31 2020 +0100
s390/ptrace: return -ENOSYS when invalid syscall is supplied
The current code returns the syscall number which an invalid
syscall number is supplied and tracing is enabled. This makes
the strace testsuite fail.
Signed-off-by: Sven Schnelle
Signed-off-by: Vasily Gorbik
which got released with 5.8. The commit missed to Cc stable and
although I've asked Sven to include it in stable I'm not sure when or
if it will show up there.
Regression Potential: Limited to s390x.
Test Case: The reproducer given above needs to output -ENOSYS instead
of 500.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1895132/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1895132] [NEW] s390x broken with unknown syscall number on kernels < 5.8
Public bug reported:
SRU Justification
Impact: On kernels prior to 5.8 when a task is in traced state (due to
audit, ptrace, or seccomp) s390x and a syscall is issued that the kernel
doesn't know about s390x will not return ENOSYS in r2 but instead will
return the syscall number. This breaks userspace all over the place. The
following program compiled on s390x will output 500 instead of -ENOSYS:
root@test:~# cat test.c
#define _GNU_SOURCE
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
static inline int dummy_inline_asm(void)
{
register long r1 asm("r1") = 500;
register long r2 asm("r2") = -1;
register long r3 asm("r3") = -1;
register long r4 asm("r4") = -1;
register long r5 asm("r5") = -1;
register long __res_r2 asm("r2");
asm volatile(
"svc 0\n\t"
: "=d"(__res_r2)
: "d"(r1), "0"(r2), "d"(r3), "d"(r4), "d"(r5)
: "memory");
return (int) __res_r2;
}
static inline int dummy_syscall(void)
{
return syscall(500, -1, -1, -1, -1);
}
int main(int argc, char *argv[])
{
printf("Uhm: %d\n", dummy_inline_asm());
printf("Uhm: %d\n", dummy_syscall());
exit(EXIT_SUCCESS);
}
This breaks LXD on s390x currently completely as well as strace.
Fix: Backport
commit cd29fa798001075a554b978df3a64e6656c25794
Author: Sven Schnelle
Date: Fri Mar 6 13:18:31 2020 +0100
s390/ptrace: return -ENOSYS when invalid syscall is supplied
The current code returns the syscall number which an invalid
syscall number is supplied and tracing is enabled. This makes
the strace testsuite fail.
Signed-off-by: Sven Schnelle
Signed-off-by: Vasily Gorbik
which got released with 5.8. The commit missed to Cc stable and although
I've asked Sven to include it in stable I'm not sure when or if it will
show up there.
Regression Potential: Limited to s390x.
Test Case: The reproducer given above needs to output -ENOSYS instead of
500.
** Affects: linux (Ubuntu)
Importance: Undecided
Status: Confirmed
** Changed in: linux (Ubuntu)
Status: New => Confirmed
** Description changed:
SRU Justification
Impact: On kernels prior to 5.8 when a task is in traced state (due to
audit, ptrace, or seccomp) s390x and a syscall is issued that the kernel
doesn't know about s390x will not return ENOSYS in r2 but instead will
return the syscall number. This breaks userspace all over the place. The
following program compiled on s390x will output 500 instead of -ENOSYS:
root@test:~# cat test.c
#define _GNU_SOURCE
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
static inline int dummy_inline_asm(void)
{
- register long r1 asm("r1") = 500;
- register long r2 asm("r2") = -1;
- register long r3 asm("r3") = -1;
- register long r4 asm("r4") = -1;
- register long r5 asm("r5") = -1;
- register long __res_r2 asm("r2");
- asm volatile(
- "svc 0\n\t"
- : "=d"(__res_r2)
- : "d"(r1), "0"(r2), "d"(r3), "d"(r4), "d"(r5)
- : "memory");
- return (int) __res_r2;
+ register long r1 asm("r1") = 500;
+ register long r2 asm("r2") = -1;
+ register long r3 asm("r3") = -1;
+ register long r4 asm("r4") = -1;
+ register long r5 asm("r5") = -1;
+ register long __res_r2 asm("r2");
+ asm volatile(
+ "svc 0\n\t"
+ : "=d"(__res_r2)
+ : "d"(r1), "0"(r2), "d"(r3), "d"(r4), "d"(r5)
+ : "memory");
+ return (int) __res_r2;
}
static inline int dummy_syscall(void)
{
- return syscall(500, -1, -1, -1, -1);
+ return syscall(500, -1, -1, -1, -1);
}
int main(int argc, char *argv[])
{
- printf("Uhm: %d\n", dummy_inline_asm());
- printf("Uhm: %d\n", dummy_syscall());
+ printf("Uhm: %d\n", dummy_inline_asm());
+ printf("Uhm: %d\n", dummy_syscall());
- exit(EXIT_SUCCESS);
+ exit(EXIT_SUCCESS);
}
+
+ This breaks LXD on s390x currently completely as well as strace.
Fix: Backport
commit cd29fa798001075a554b978df3a64e6656c25794
Author: Sven Schnelle
Date: Fri Mar 6 13:18:31 2020 +0100
- s390/ptrace: return -ENOSYS when invalid syscall is supplied
+ s390/ptrace: return -ENOSYS when invalid syscall is supplied
- The current code returns the syscall number which an invalid
- syscall number is supplied and tracing is enabled. This makes
- the strace testsuite fail.
+ The current code returns the syscall number which an invalid
+ syscall number is supplied and tracing is enabled. This makes
+ the strace testsuite fail.
- Signed-off-by: Sven
[Kernel-packages] [Bug 1884767] Re: shiftfs: fix btrfs regression
** Tags removed: verification-needed-eoan ** Tags added: verification-done-eoan -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1884767 Title: shiftfs: fix btrfs regression Status in linux package in Ubuntu: In Progress Status in linux source package in Eoan: Fix Committed Bug description: SRU Justification Impact: The patch commit cfaa482afb97e3c05d020af80b897b061109d51f Author: Christian Brauner Date: Tue Apr 14 22:26:53 2020 +0200 UBUNTU: SAUCE: shiftfs: fix dentry revalidation BugLink: https://bugs.launchpad.net/bugs/1872757 to fix https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1872757 regresses various btrfs + shiftfs users. Creating a btrfs subvolume, deleting it, and then trying to recreate it will cause EEXIST to be returned. It also leaves some files in a half-visible state because they are not revalidated correctly. Faulty behavior such as this can be reproduced via: btrfs subvolume create my-subvol btrfs subvolume delete my-subvol Fix: We need to revert this patch restoring the old behavior. This will briefly resurface https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1872757 which I will fix in a follow-up patch on top of this revert. We basically split the part that fixes https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1872757 out of the revert. Regression Potential: Limited to shiftfs. Test Case: Build a kernel with fix applied and run above reproducer. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1884767/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1884635] Re: lxc 1:4.0.2-0ubuntu1 ADT test failure with linux-5.8 5.8.0-1.2
** Changed in: linux (Ubuntu) Status: Incomplete => Confirmed ** Changed in: linux (Ubuntu) Status: Confirmed => In Progress ** Changed in: linux (Ubuntu) Assignee: (unassigned) => Christian Brauner (cbrauner) -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1884635 Title: lxc 1:4.0.2-0ubuntu1 ADT test failure with linux-5.8 5.8.0-1.2 Status in linux package in Ubuntu: In Progress Status in lxc package in Ubuntu: Invalid Bug description: Testing failed on: amd64: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-groovy-canonical-kernel-team-bootstrap/groovy/amd64/l/lxc/20200619_210334_814e1@/log.gz arm64: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-groovy-canonical-kernel-team-bootstrap/groovy/arm64/l/lxc/20200619_213805_39c53@/log.gz ppc64el: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-groovy-canonical-kernel-team-bootstrap/groovy/ppc64el/l/lxc/20200619_210431_b275f@/log.gz s390x: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-groovy-canonical-kernel-team-bootstrap/groovy/s390x/l/lxc/20200619_210417_54a16@/log.gz To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1884635/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1884635] Re: lxc 1:4.0.2-0ubuntu1 ADT test failure with linux-5.8 5.8.0-1.2
** Also affects: linux (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1884635 Title: lxc 1:4.0.2-0ubuntu1 ADT test failure with linux-5.8 5.8.0-1.2 Status in linux package in Ubuntu: Incomplete Status in lxc package in Ubuntu: Invalid Bug description: Testing failed on: amd64: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-groovy-canonical-kernel-team-bootstrap/groovy/amd64/l/lxc/20200619_210334_814e1@/log.gz arm64: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-groovy-canonical-kernel-team-bootstrap/groovy/arm64/l/lxc/20200619_213805_39c53@/log.gz ppc64el: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-groovy-canonical-kernel-team-bootstrap/groovy/ppc64el/l/lxc/20200619_210431_b275f@/log.gz s390x: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-groovy-canonical-kernel-team-bootstrap/groovy/s390x/l/lxc/20200619_210417_54a16@/log.gz To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1884635/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1884767] [NEW] shiftfs: fix btrfs regression
Public bug reported: SRU Justification Impact: The patch commit cfaa482afb97e3c05d020af80b897b061109d51f Author: Christian Brauner Date: Tue Apr 14 22:26:53 2020 +0200 UBUNTU: SAUCE: shiftfs: fix dentry revalidation BugLink: https://bugs.launchpad.net/bugs/1872757 to fix https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1872757 regresses various btrfs + shiftfs users. Creating a btrfs subvolume, deleting it, and then trying to recreate it will cause EEXIST to be returned. It also leaves some files in a half-visible state because they are not revalidated correctly. Faulty behavior such as this can be reproduced via: btrfs subvolume create my-subvol btrfs subvolume delete my-subvol Fix: We need to revert this patch restoring the old behavior. This will briefly resurface https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1872757 which I will fix in a follow-up patch on top of this revert. We basically split the part that fixes https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1872757 out of the revert. Regression Potential: Limited to shiftfs. Test Case: Build a kernel with fix applied and run above reproducer. ** Affects: linux (Ubuntu) Importance: Undecided Assignee: Christian Brauner (cbrauner) Status: In Progress ** Changed in: linux (Ubuntu) Status: New => Incomplete ** Changed in: linux (Ubuntu) Status: Incomplete => In Progress ** Changed in: linux (Ubuntu) Assignee: (unassigned) => Christian Brauner (cbrauner) -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1884767 Title: shiftfs: fix btrfs regression Status in linux package in Ubuntu: In Progress Bug description: SRU Justification Impact: The patch commit cfaa482afb97e3c05d020af80b897b061109d51f Author: Christian Brauner Date: Tue Apr 14 22:26:53 2020 +0200 UBUNTU: SAUCE: shiftfs: fix dentry revalidation BugLink: https://bugs.launchpad.net/bugs/1872757 to fix https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1872757 regresses various btrfs + shiftfs users. Creating a btrfs subvolume, deleting it, and then trying to recreate it will cause EEXIST to be returned. It also leaves some files in a half-visible state because they are not revalidated correctly. Faulty behavior such as this can be reproduced via: btrfs subvolume create my-subvol btrfs subvolume delete my-subvol Fix: We need to revert this patch restoring the old behavior. This will briefly resurface https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1872757 which I will fix in a follow-up patch on top of this revert. We basically split the part that fixes https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1872757 out of the revert. Regression Potential: Limited to shiftfs. Test Case: Build a kernel with fix applied and run above reproducer. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1884767/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1879688] Re: shiftfs: fix btrfs snapshot deletion
** Tags removed: verification-needed-eoan ** Tags added: verification-done-eoan -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1879688 Title: shiftfs: fix btrfs snapshot deletion Status in linux package in Ubuntu: Confirmed Status in linux source package in Eoan: Fix Committed Status in linux source package in Focal: Fix Committed Status in linux source package in Groovy: Confirmed Bug description: SRU Justification Impact: Stéphane discovered a problem during NorthSec which makes heavy use of shiftfs. In containers with a btrfs root filesystem that make use of shiftfs userns root is not able to delete subvolumes that have been created by another users which it would be able to do otherwise. This makes it impossible for LXD to delete nested containers. To reproduce this as root in the container: btrfs subvolume create my-subvol chown 1000:1000 my-subvol btrfs subvolume delete my-subvol The deletion will fail when it should have succeeded. Fix: For improved security we drop all capabilities before we forward btrfs ioctls in shiftfs. To fix the above problem we can retain the CAP_DAC_OVERRIDE capability only if we are userns root. Regression Potential: Limited to shiftfs. Even though we drop all capabilities in all capability sets we really mostly care about dropping CAP_SYS_ADMIN and we mostly do this for ioctl that e.g. allow you to traverse the btrfs filesystem and with CAP_SYS_ADMIN retained in the underlay would allow you to list subvolumes you shouldn't be able to list. This fix only retains CAP_DAC_OVERRIDE and only for the deletion of subvolumes and only by userns root. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1879688/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1879688] Re: shiftfs: fix btrfs snapshot deletion
Confirmed this is fixed: brauner@wittgenstein|~ > lxc shell f1-vm root@f1-vm:~# lxc shell f1 root@f1:~# btrfs subvolume create my-subvol root@f1:~# chown 1000:1000 my-subvol root@f1:~# btrfs subvolume delete my-subvol Delete subvolume (no-commit): '/root/my-subvol' ** Tags removed: verification-needed-focal ** Tags added: verification-done-focal -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1879688 Title: shiftfs: fix btrfs snapshot deletion Status in linux package in Ubuntu: Confirmed Status in linux source package in Eoan: Fix Committed Status in linux source package in Focal: Fix Committed Status in linux source package in Groovy: Confirmed Bug description: SRU Justification Impact: Stéphane discovered a problem during NorthSec which makes heavy use of shiftfs. In containers with a btrfs root filesystem that make use of shiftfs userns root is not able to delete subvolumes that have been created by another users which it would be able to do otherwise. This makes it impossible for LXD to delete nested containers. To reproduce this as root in the container: btrfs subvolume create my-subvol chown 1000:1000 my-subvol btrfs subvolume delete my-subvol The deletion will fail when it should have succeeded. Fix: For improved security we drop all capabilities before we forward btrfs ioctls in shiftfs. To fix the above problem we can retain the CAP_DAC_OVERRIDE capability only if we are userns root. Regression Potential: Limited to shiftfs. Even though we drop all capabilities in all capability sets we really mostly care about dropping CAP_SYS_ADMIN and we mostly do this for ioctl that e.g. allow you to traverse the btrfs filesystem and with CAP_SYS_ADMIN retained in the underlay would allow you to list subvolumes you shouldn't be able to list. This fix only retains CAP_DAC_OVERRIDE and only for the deletion of subvolumes and only by userns root. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1879688/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1879688] [NEW] shiftfs: fix btrfs snapshot deletion
Public bug reported: SRU Justification Impact: Stéphane discovered a problem during NorthSec which makes heavy use of shiftfs. In containers with a btrfs root filesystem that make use of shiftfs userns root is not able to delete subvolumes that have been created by another users which it would be able to do otherwise. This makes it impossible for LXD to delete nested containers. To reproduce this as root in the container: btrfs subvolume create my-subvol chown 1000:1000 my-subvol btrfs subvolume delete my-subvol The deletion will fail when it should have succeeded. Fix: For improved security we drop all capabilities before we forward btrfs ioctls in shiftfs. To fix the above problem we can retain the CAP_DAC_OVERRIDE capability only if we are userns root. Regression Potential: Limited to shiftfs. Even though we drop all capabilities in all capability sets we really mostly care about dropping CAP_SYS_ADMIN and we mostly do this for ioctl that e.g. allow you to traverse the btrfs filesystem and with CAP_SYS_ADMIN retained in the underlay would allow you to list subvolumes you shouldn't be able to list. This fix only retains CAP_DAC_OVERRIDE and only for the deletion of subvolumes and only by userns root. ** Affects: linux (Ubuntu) Importance: Undecided Assignee: Christian Brauner (cbrauner) Status: Confirmed ** Changed in: linux (Ubuntu) Status: New => Confirmed ** Changed in: linux (Ubuntu) Assignee: (unassigned) => Christian Brauner (cbrauner) -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1879688 Title: shiftfs: fix btrfs snapshot deletion Status in linux package in Ubuntu: Confirmed Bug description: SRU Justification Impact: Stéphane discovered a problem during NorthSec which makes heavy use of shiftfs. In containers with a btrfs root filesystem that make use of shiftfs userns root is not able to delete subvolumes that have been created by another users which it would be able to do otherwise. This makes it impossible for LXD to delete nested containers. To reproduce this as root in the container: btrfs subvolume create my-subvol chown 1000:1000 my-subvol btrfs subvolume delete my-subvol The deletion will fail when it should have succeeded. Fix: For improved security we drop all capabilities before we forward btrfs ioctls in shiftfs. To fix the above problem we can retain the CAP_DAC_OVERRIDE capability only if we are userns root. Regression Potential: Limited to shiftfs. Even though we drop all capabilities in all capability sets we really mostly care about dropping CAP_SYS_ADMIN and we mostly do this for ioctl that e.g. allow you to traverse the btrfs filesystem and with CAP_SYS_ADMIN retained in the underlay would allow you to list subvolumes you shouldn't be able to list. This fix only retains CAP_DAC_OVERRIDE and only for the deletion of subvolumes and only by userns root. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1879688/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1879196] Re: 'shifted' (shiftfs) FS mount became inconsistent with host FS; resolved by dropping caches
James, can you try this kernel, please: https://drive.google.com/open?id =19iTwaFSYNS95_I-gD_rvFoV9cMAfy6io -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1879196 Title: 'shifted' (shiftfs) FS mount became inconsistent with host FS; resolved by dropping caches Status in linux package in Ubuntu: In Progress Status in linux source package in Eoan: Triaged Status in linux source package in Focal: Triaged Bug description: On Ubuntu 20.04 with linux-image-5.4.0-30-generic from the Canonical Kernel Team's proposed PPA, I ran into the following problem with using a shiftfs 'shifted' ext4 FS mount inside a LXD container. On the host, I created a file (in emacs) that was in no way special (single line text file): james@malefic:~/projects/ethq/deb$ stat ethq-0.6.1~git2020517/debian/ethq.install File: ethq-0.6.1~git2020517/debian/ethq.install Size: 15 Blocks: 8 IO Block: 4096 regular file Device: fd01h/64769dInode: 7085913 Links: 1 Access: (0664/-rw-rw-r--) Uid: ( 1000/ james) Gid: ( 1000/ james) Access: 2020-05-17 22:48:36.274528130 +0100 Modify: 2020-05-17 22:37:17.676232019 +0100 Change: 2020-05-17 22:37:17.676232019 +0100 Birth: - james@malefic:~/projects/ethq/deb$ stat ethq-0.6.1~git2020517/debian/rules But in the container, I saw this: ubuntu@ethq-build:~/ethq/deb/ethq-0.6.1~git2020517$ ls -l debian/ ls: cannot access 'debian/ethq.install': No such file or directory total 20 -rw-rw-r-- 1 ubuntu ubuntu 150 May 17 21:25 changelog -rw-r--r-- 1 ubuntu ubuntu 2 May 17 21:36 compat -rw-rw-r-- 1 ubuntu ubuntu 514 May 17 21:14 control -rw-rw-r-- 1 ubuntu ubuntu 720 May 17 21:20 copyright -? ? ? ??? ethq.install -rwxr-xr-x 1 ubuntu ubuntu 30 May 17 21:35 rules ubuntu@ethq-build:~/ethq/deb/ethq-0.6.1~git2020517$ stat debian/ethq.install stat: cannot stat 'debian/ethq.install': No such file or directory ubuntu@ethq-build:~/ethq/deb/ethq-0.6.1~git2020517$ On a suggestion from Stephane Graber, I tried running: echo 3 > /proc/sys/vm/drop_caches Which seemed to resolve the problem: ubuntu@ethq-build:~/ethq/deb/ethq-0.6.1~git2020517$ stat debian/ethq.install File: 'debian/ethq.install' Size: 15 Blocks: 8 IO Block: 4096 regular file Device: fd01h/64769dInode: 7085913 Links: 1 Access: (0664/-rw-rw-r--) Uid: ( 1000/ ubuntu) Gid: ( 1000/ ubuntu) Access: 2020-05-17 21:48:36.274528130 + Modify: 2020-05-17 21:37:17.676232019 + Change: 2020-05-17 21:37:17.676232019 + Birth: - ubuntu@ethq-build:~/ethq/deb/ethq-0.6.1~git2020517$ To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1879196/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1879454] Re: Set CONFIG_USELIB=n in Ubuntu kernels
So I've gone through codesearch on Debian and there are no users apart from a bunch of defines for __NR_uselib when it isn't defined. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1879454 Title: Set CONFIG_USELIB=n in Ubuntu kernels Status in linux package in Ubuntu: Confirmed Bug description: We're currently planning to be more proactive in deprecating the uselib() syscall similar to how we deprecated the sysctl() syscall. This will be a long process of course but the starting point is to set CONFIG_USELIB=n in all new Ubuntu versions. I spoke to Eric and apparently RHEL 8 has it disabled too. The regression potential is quite minimal as this interface should have very few users and libc hasn't used it since libc4 or libc5. I was wondering what people's opinion on this were. The thread is: https://lore.kernel.org/lkml/20200518130251.zih2s32q2rxhxg6f@wittgenstein https://lore.kernel.org/lkml/cag48ez1fspvvypjso6badg7vb84ktudqjrk1d7vyhrm06ai...@mail.gmail.com https://lore.kernel.org/lkml/20200518144627.sv5nesysvtgxwkp7@wittgenstein https://lore.kernel.org/lkml/87blmk3ig4@x220.int.ebiederm.org To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1879454/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1879454] [NEW] Set CONFIG_USELIB=n in Ubuntu kernels
Public bug reported: We're currently planning to be more proactive in deprecating the uselib() syscall similar to how we deprecated the sysctl() syscall. This will be a long process of course but the starting point is to set CONFIG_USELIB=n in all new Ubuntu versions. I spoke to Eric and apparently RHEL 8 has it disabled too. The regression potential is quite minimal as this interface should have very few users and libc hasn't used it since libc4 or libc5. I was wondering what people's opinion on this were. The thread is: https://lore.kernel.org/lkml/20200518130251.zih2s32q2rxhxg6f@wittgenstein https://lore.kernel.org/lkml/cag48ez1fspvvypjso6badg7vb84ktudqjrk1d7vyhrm06ai...@mail.gmail.com https://lore.kernel.org/lkml/20200518144627.sv5nesysvtgxwkp7@wittgenstein https://lore.kernel.org/lkml/87blmk3ig4@x220.int.ebiederm.org ** Affects: linux (Ubuntu) Importance: Undecided Status: Confirmed ** Changed in: linux (Ubuntu) Status: New => Confirmed -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1879454 Title: Set CONFIG_USELIB=n in Ubuntu kernels Status in linux package in Ubuntu: Confirmed Bug description: We're currently planning to be more proactive in deprecating the uselib() syscall similar to how we deprecated the sysctl() syscall. This will be a long process of course but the starting point is to set CONFIG_USELIB=n in all new Ubuntu versions. I spoke to Eric and apparently RHEL 8 has it disabled too. The regression potential is quite minimal as this interface should have very few users and libc hasn't used it since libc4 or libc5. I was wondering what people's opinion on this were. The thread is: https://lore.kernel.org/lkml/20200518130251.zih2s32q2rxhxg6f@wittgenstein https://lore.kernel.org/lkml/cag48ez1fspvvypjso6badg7vb84ktudqjrk1d7vyhrm06ai...@mail.gmail.com https://lore.kernel.org/lkml/20200518144627.sv5nesysvtgxwkp7@wittgenstein https://lore.kernel.org/lkml/87blmk3ig4@x220.int.ebiederm.org To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1879454/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1879196] Re: 'shifted' (shiftfs) FS mount became inconsistent with host FS; resolved by dropping caches
I have a fix for this note, that this is a regression we introduced by another fix. I also want to put this cautious note here so people better understand why shiftfs has such bugs and why they are not simple idiot regressions but rather intricate to fix: Note, in general it's not advisable to directly modify the underlay while a shiftfs mount is on top. In some way this means we need to keep two caches in sync and it's hard enough to keep a single cache happy. But shiftfs' use-case is inherently prone to be used for exactly that. So this is something we have to navigate carefully and honestly we have no full model upstream that does the same. Overlayfs has the copy-up behavior which let's it get around most of the issues but we don't have it and ecryptfs is broken in such scenarios which we verified quite a while back. In any case, I built a kernel with this patch and re-ran all regressions that are related to this that we have so far (cf. [1], [2], and [3]). None of them were reproducible with this patch here. So we still fix the ESTALE issue but also keep underlay and overlay in sync. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1879196 Title: 'shifted' (shiftfs) FS mount became inconsistent with host FS; resolved by dropping caches Status in linux package in Ubuntu: In Progress Bug description: On Ubuntu 20.04 with linux-image-5.4.0-30-generic from the Canonical Kernel Team's proposed PPA, I ran into the following problem with using a shiftfs 'shifted' ext4 FS mount inside a LXD container. On the host, I created a file (in emacs) that was in no way special (single line text file): james@malefic:~/projects/ethq/deb$ stat ethq-0.6.1~git2020517/debian/ethq.install File: ethq-0.6.1~git2020517/debian/ethq.install Size: 15 Blocks: 8 IO Block: 4096 regular file Device: fd01h/64769dInode: 7085913 Links: 1 Access: (0664/-rw-rw-r--) Uid: ( 1000/ james) Gid: ( 1000/ james) Access: 2020-05-17 22:48:36.274528130 +0100 Modify: 2020-05-17 22:37:17.676232019 +0100 Change: 2020-05-17 22:37:17.676232019 +0100 Birth: - james@malefic:~/projects/ethq/deb$ stat ethq-0.6.1~git2020517/debian/rules But in the container, I saw this: ubuntu@ethq-build:~/ethq/deb/ethq-0.6.1~git2020517$ ls -l debian/ ls: cannot access 'debian/ethq.install': No such file or directory total 20 -rw-rw-r-- 1 ubuntu ubuntu 150 May 17 21:25 changelog -rw-r--r-- 1 ubuntu ubuntu 2 May 17 21:36 compat -rw-rw-r-- 1 ubuntu ubuntu 514 May 17 21:14 control -rw-rw-r-- 1 ubuntu ubuntu 720 May 17 21:20 copyright -? ? ? ??? ethq.install -rwxr-xr-x 1 ubuntu ubuntu 30 May 17 21:35 rules ubuntu@ethq-build:~/ethq/deb/ethq-0.6.1~git2020517$ stat debian/ethq.install stat: cannot stat 'debian/ethq.install': No such file or directory ubuntu@ethq-build:~/ethq/deb/ethq-0.6.1~git2020517$ On a suggestion from Stephane Graber, I tried running: echo 3 > /proc/sys/vm/drop_caches Which seemed to resolve the problem: ubuntu@ethq-build:~/ethq/deb/ethq-0.6.1~git2020517$ stat debian/ethq.install File: 'debian/ethq.install' Size: 15 Blocks: 8 IO Block: 4096 regular file Device: fd01h/64769dInode: 7085913 Links: 1 Access: (0664/-rw-rw-r--) Uid: ( 1000/ ubuntu) Gid: ( 1000/ ubuntu) Access: 2020-05-17 21:48:36.274528130 + Modify: 2020-05-17 21:37:17.676232019 + Change: 2020-05-17 21:37:17.676232019 + Birth: - ubuntu@ethq-build:~/ethq/deb/ethq-0.6.1~git2020517$ To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1879196/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1879196] Re: 'shifted' (shiftfs) FS mount became inconsistent with host FS; resolved by dropping caches
** Changed in: linux (Ubuntu) Status: Incomplete => In Progress ** Changed in: linux (Ubuntu) Assignee: (unassigned) => Christian Brauner (cbrauner) -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1879196 Title: 'shifted' (shiftfs) FS mount became inconsistent with host FS; resolved by dropping caches Status in linux package in Ubuntu: In Progress Bug description: On Ubuntu 20.04 with linux-image-5.4.0-30-generic from the Canonical Kernel Team's proposed PPA, I ran into the following problem with using a shiftfs 'shifted' ext4 FS mount inside a LXD container. On the host, I created a file (in emacs) that was in no way special (single line text file): james@malefic:~/projects/ethq/deb$ stat ethq-0.6.1~git2020517/debian/ethq.install File: ethq-0.6.1~git2020517/debian/ethq.install Size: 15 Blocks: 8 IO Block: 4096 regular file Device: fd01h/64769dInode: 7085913 Links: 1 Access: (0664/-rw-rw-r--) Uid: ( 1000/ james) Gid: ( 1000/ james) Access: 2020-05-17 22:48:36.274528130 +0100 Modify: 2020-05-17 22:37:17.676232019 +0100 Change: 2020-05-17 22:37:17.676232019 +0100 Birth: - james@malefic:~/projects/ethq/deb$ stat ethq-0.6.1~git2020517/debian/rules But in the container, I saw this: ubuntu@ethq-build:~/ethq/deb/ethq-0.6.1~git2020517$ ls -l debian/ ls: cannot access 'debian/ethq.install': No such file or directory total 20 -rw-rw-r-- 1 ubuntu ubuntu 150 May 17 21:25 changelog -rw-r--r-- 1 ubuntu ubuntu 2 May 17 21:36 compat -rw-rw-r-- 1 ubuntu ubuntu 514 May 17 21:14 control -rw-rw-r-- 1 ubuntu ubuntu 720 May 17 21:20 copyright -? ? ? ??? ethq.install -rwxr-xr-x 1 ubuntu ubuntu 30 May 17 21:35 rules ubuntu@ethq-build:~/ethq/deb/ethq-0.6.1~git2020517$ stat debian/ethq.install stat: cannot stat 'debian/ethq.install': No such file or directory ubuntu@ethq-build:~/ethq/deb/ethq-0.6.1~git2020517$ On a suggestion from Stephane Graber, I tried running: echo 3 > /proc/sys/vm/drop_caches Which seemed to resolve the problem: ubuntu@ethq-build:~/ethq/deb/ethq-0.6.1~git2020517$ stat debian/ethq.install File: 'debian/ethq.install' Size: 15 Blocks: 8 IO Block: 4096 regular file Device: fd01h/64769dInode: 7085913 Links: 1 Access: (0664/-rw-rw-r--) Uid: ( 1000/ ubuntu) Gid: ( 1000/ ubuntu) Access: 2020-05-17 21:48:36.274528130 + Modify: 2020-05-17 21:37:17.676232019 + Change: 2020-05-17 21:37:17.676232019 + Birth: - ubuntu@ethq-build:~/ethq/deb/ethq-0.6.1~git2020517$ To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1879196/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1872094] Re: shiftfs: broken shiftfs nesting
** Changed in: linux (Ubuntu) Status: In Progress => Fix Committed -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1872094 Title: shiftfs: broken shiftfs nesting Status in linux package in Ubuntu: Fix Committed Status in linux source package in Eoan: Fix Committed Status in linux source package in Focal: Fix Committed Bug description: SRU Justification Impact: When nested containers use shiftfs and they have different id mappings the nested container lacks privileges to create any files in its root filesystem unless the directory in question is very permissive. This prevents nested containers from being usable. Here is a reproducer as given by Stéphane: Reproducer: - lxc init images:ubuntu/bionic b1 -c security.nesting=true - Confirm b1 uses shiftfs and uses the default map root@b1:~# cat /proc/self/uid_map 0100 10 root@b1:~# grep shiftfs /proc/self/mountinfo 3702 2266 0:92 / / rw,relatime - shiftfs /var/lib/lxd/storage-pools/default/containers/b1/rootfs rw,passthrough=3 - Install LXD snap in there - snap set lxd shiftfs.enable=true - systemctl reload snap.lxd.daemon - lxd init --auto - lxc launch images:alpine/edge a1 - Confirm that a1 uses a different map than b1 - Confirm that a1 uses shiftfs - touch /etc/a should fail with EACCES Fix: Instead of recording the credentials of the process that created the innermost shiftfs mount we need to record the credentials of the lowers creator of the first shiftfs mark mount since we always refer back to the lowers mount to get around vfs layering restrictions. Regression Potential: Limited to shiftfs. Test Case: Built a kernel with the mentioned fix and ran the reproducer. The issue was not reproducible. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1872094/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1824719] Re: shiftfs: Allow stacking overlayfs on top
** Changed in: linux (Ubuntu) Status: In Progress => Fix Released -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1824719 Title: shiftfs: Allow stacking overlayfs on top Status in linux package in Ubuntu: Fix Released Bug description: Shiftfs right now prevents stacking overlayfs on top of it which unfortunately means all users of Docker as well as some nested LXC users which aren't using btrfs are going to break when they get switched over to shiftfs. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1824719/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1872757] Re: shiftfs: O_TMPFILE reports ESTALE
** Changed in: linux (Ubuntu)
Status: In Progress => Fix Committed
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1872757
Title:
shiftfs: O_TMPFILE reports ESTALE
Status in linux package in Ubuntu:
Fix Committed
Status in linux source package in Eoan:
Fix Committed
Status in linux source package in Focal:
Fix Committed
Bug description:
SRU Justification
Impact: Christian Kellner reported that creating temporary files via
O_TMPFILE shiftfs reports ESTALE. This can be reproduced via:
import tempfile
import os
def test():
with tempfile.TemporaryFile() as fd:
fd.write("data".encode('utf-8'))
# re-open the file to get a read-only file descriptor
return open(f"/proc/self/fd/{fd.fileno()}", "r")
def main():
fd = test()
fd.close()
if __name__ == "__main__":
main()
a similar issue was reported here:
https://github.com/systemd/systemd/issues/14861
Fix: Our revalidate methods were very opinionated about whether or not
a dentry was valid when we really should've just let the underlay tell
us what's what. This has led to bugs where a ESTALE was returned for
e.g. temporary files that were created and directly re-opened
afterwards through /proc//fd/. When a file is
re-opened through /proc//fd/ LOOKUP_JUMP is set and the vfs
will revalidate via d_weak_revalidate(). Since the file has been
unhashed or even already gone negative we'd fail the open when we
should've succeeded.
I had also foolishly provided a .tmpfile method which so far only has
caused us trouble. If we really need this then we can reimplement it
properly but I doubt it. Remove it for now.
Regression Potential: Limited to shiftfs.
Test Case: Build a kernel with fix applied and run above reproducer.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1872757/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1872094] Re: shiftfs: broken shiftfs nesting
** Tags removed: verification-needed-eoan verification-needed-focal ** Tags added: verification-done-eoan verification-done-focal -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1872094 Title: shiftfs: broken shiftfs nesting Status in linux package in Ubuntu: In Progress Status in linux source package in Eoan: Fix Committed Status in linux source package in Focal: Fix Committed Bug description: SRU Justification Impact: When nested containers use shiftfs and they have different id mappings the nested container lacks privileges to create any files in its root filesystem unless the directory in question is very permissive. This prevents nested containers from being usable. Here is a reproducer as given by Stéphane: Reproducer: - lxc init images:ubuntu/bionic b1 -c security.nesting=true - Confirm b1 uses shiftfs and uses the default map root@b1:~# cat /proc/self/uid_map 0100 10 root@b1:~# grep shiftfs /proc/self/mountinfo 3702 2266 0:92 / / rw,relatime - shiftfs /var/lib/lxd/storage-pools/default/containers/b1/rootfs rw,passthrough=3 - Install LXD snap in there - snap set lxd shiftfs.enable=true - systemctl reload snap.lxd.daemon - lxd init --auto - lxc launch images:alpine/edge a1 - Confirm that a1 uses a different map than b1 - Confirm that a1 uses shiftfs - touch /etc/a should fail with EACCES Fix: Instead of recording the credentials of the process that created the innermost shiftfs mount we need to record the credentials of the lowers creator of the first shiftfs mark mount since we always refer back to the lowers mount to get around vfs layering restrictions. Regression Potential: Limited to shiftfs. Test Case: Built a kernel with the mentioned fix and ran the reproducer. The issue was not reproducible. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1872094/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1872757] Re: shiftfs: O_TMPFILE reports ESTALE
** Tags removed: verification-needed-focal
** Tags added: verification-done-focal
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1872757
Title:
shiftfs: O_TMPFILE reports ESTALE
Status in linux package in Ubuntu:
In Progress
Status in linux source package in Eoan:
Fix Committed
Status in linux source package in Focal:
Fix Committed
Bug description:
SRU Justification
Impact: Christian Kellner reported that creating temporary files via
O_TMPFILE shiftfs reports ESTALE. This can be reproduced via:
import tempfile
import os
def test():
with tempfile.TemporaryFile() as fd:
fd.write("data".encode('utf-8'))
# re-open the file to get a read-only file descriptor
return open(f"/proc/self/fd/{fd.fileno()}", "r")
def main():
fd = test()
fd.close()
if __name__ == "__main__":
main()
a similar issue was reported here:
https://github.com/systemd/systemd/issues/14861
Fix: Our revalidate methods were very opinionated about whether or not
a dentry was valid when we really should've just let the underlay tell
us what's what. This has led to bugs where a ESTALE was returned for
e.g. temporary files that were created and directly re-opened
afterwards through /proc//fd/. When a file is
re-opened through /proc//fd/ LOOKUP_JUMP is set and the vfs
will revalidate via d_weak_revalidate(). Since the file has been
unhashed or even already gone negative we'd fail the open when we
should've succeeded.
I had also foolishly provided a .tmpfile method which so far only has
caused us trouble. If we really need this then we can reimplement it
properly but I doubt it. Remove it for now.
Regression Potential: Limited to shiftfs.
Test Case: Build a kernel with fix applied and run above reproducer.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1872757/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
Re: [Kernel-packages] [Bug 1876645] Re: Unable to handle kernel pointer dereference in virtual kernel address space on Eoan
On Wed, May 06, 2020 at 10:32:19AM -, Kleber Sacilotto de Souza wrote: > With the fixup patch applied, I could not reproduce the issue anymore on > both Eoan and Focal running ubuntu_fan_smoke_test and > ubuntu_docker_smoke_test. Sweet, thank you and sorry for the rebase mess-up with Andrei's patch. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1876645 Title: Unable to handle kernel pointer dereference in virtual kernel address space on Eoan Status in ubuntu-kernel-tests: New Status in linux package in Ubuntu: In Progress Status in linux source package in Eoan: In Progress Status in linux source package in Focal: In Progress Bug description: Issue spotted on Eoan zVM / LPAR It looks like this happens when running the ubunut_fan_smoke_test (jenkins job hang with this one) [ 1225.137764] docker0: port 1(veth2fda0c6) entered blocking state [ 1225.137767] docker0: port 1(veth2fda0c6) entered disabled state [ 1225.138023] device veth2fda0c6 entered promiscuous mode [ 1225.148523] Unable to handle kernel pointer dereference in virtual kernel address space [ 1225.148529] Failing address: 6f766c5f646f5000 TEID: 6f766c5f646f5803 [ 1225.148531] Fault in home space mode while using kernel ASCE. [ 1225.148533] AS:00070d94c007 R3:0024 [ 1225.148575] Oops: 0038 ilc:3 [#1] SMP [ 1225.148578] Modules linked in: veth xt_nat vxlan ip6_udp_tunnel udp_tunnel nf_conntrack_netlink xfrm_user xfrm_algo xt_addrtype br_netfilter unix_diag sctp cuse vhost_net tap vhost_vsock vmw_vsock_virtio_transport_common vhost vsock dccp_ipv4 dccp algif_rng aegis128 aegis128l aegis256 morus1280 morus640 algif_aead anubis fcrypt khazad seed sm4_generic tea md4 michael_mic nhpoly1305 poly1305_generic rmd128 rmd160 rmd256 rmd320 sha3_generic sm3_generic streebog_generic tgr192 wp512 xxhash_generic algif_hash blowfish_generic blowfish_common cast5_generic salsa20_generic chacha_generic camellia_generic cast6_generic cast_common serpent_generic twofish_generic twofish_common algif_skcipher af_alg xt_conntrack ipt_REJECT nf_reject_ipv4 ip6table_mangle ip6table_nat nf_tables nfnetlink ip6table_filter ip6_tables iptable_mangle xt_CHECKSUM iptable_nat xt_MASQUERADE xt_tcpudp bridge iptable_filter bpfilter aufs overlay 8021q garp stp mrp llc openvswitch nsh nf_conncount nf_nat nf_conntrack [ 1225.148622] nf_defrag_ipv6 nf_defrag_ipv4 binfmt_misc zfs(PO) zunicode(PO) zavl(PO) icp(PO) zlua(PO) zcommon(PO) znvpair(PO) spl(O) genwqe_card crc_itu_t chsc_sch eadm_sch ctcm fsm vfio_ccw vfio_mdev mdev vfio_iommu_type1 vfio sch_fq_codel nfsd auth_rpcgss nfs_acl lockd grace sunrpc ip_tables x_tables btrfs zstd_compress zlib_deflate raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c raid1 raid0 linear dm_service_time mlx4_ib ib_uverbs mlx4_en ptp ib_core pps_core pkey zcrypt crc32_vx_s390 ghash_s390 prng aes_s390 des_s390 qeth_l2 des_generic sha512_s390 sha256_s390 sha1_s390 sha_common mlx4_core zfcp scsi_transport_fc qeth qdio ccwgroup dasd_eckd_mod dasd_mod scsi_dh_emc scsi_dh_rdac scsi_dh_alua dm_multipath [ 1225.148711] CPU: 4 PID: 161930 Comm: dockerd Tainted: P O 5.3.0-52-generic #46-Ubuntu [ 1225.148714] Hardware name: IBM 2964 N63 400 (LPAR) [ 1225.148716] Krnl PSW : 0704d0018000 03ff808e972a (ovl_open_realfile+0x4a/0x148 [overlay]) [ 1225.148734]R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:1 PM:0 RI:0 EA:3 [ 1225.148736] Krnl GPRS: 0064 6f766c5f646f5f6d 0007a14ac300 0003a5df6600 [ 1225.148738]8000 0001 0003 000372e45278 [ 1225.148740]03ff808ea508 000304048000 0005c7f32b68 00064a2ab900 [ 1225.148742]0003a5df6600 03ff808f31d8 03ff808e971a 03e009c0faf8 [ 1225.148749] Krnl Code: 03ff808e971a: a59a0404 oilh%r9,1028 03ff808e971e: e310f0c4 lg %r1,192(%r15) #03ff808e9724: e31010680004 lg %r1,104(%r1) >03ff808e972a: e3101064 lg %r1,96(%r1) 03ff808e9730: b9040082 lgr %r8,%r2 03ff808e9734: c21c6a656a62 cgfi %r1,1785031266 03ff808e973a: b9140039 lgfr%r3,%r9 03ff808e973e: e3100344 lg %r1,832 [ 1225.148766] Call Trace: [ 1225.148769] ([<>] 0x0) [ 1225.148774] [<03ff808ea582>] ovl_open+0x7a/0xc0 [overlay] [ 1225.148780] [<00070cbf2c04>] do_dentry_open+0x1fc/0x3b0 [ 1225.148784] [<00070cc0afd2>] do_last+0x1ba/0x970 [ 1225.148786] [<00070cc0b80e>] path_openat+0x86/0x2b8 [
[Kernel-packages] [Bug 1857257] Re: linux-image-5.0.0-35-generic breaks checkpointing of container
Fix here: https://lists.ubuntu.com/archives/kernel-team/2020-May/109617.html -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1857257 Title: linux-image-5.0.0-35-generic breaks checkpointing of container Status in linux package in Ubuntu: In Progress Status in linux source package in Eoan: Fix Committed Status in linux source package in Focal: Fix Committed Bug description: Trying to checkpoint a container (docker/podman) on 18.04 fails starting with linux-image-5.0.0-35-generic. We (CRIU upstream) see this in Travis starting a few weeks ago. Manually testing it locally shows that linux-image-5.0.0-32-generic still works and linux- image-5.0.0-35-generic does not longer work. It seems to be overlayfs related, at least that is what we believe. The CRIU error message we see is: (00.170944) Error (criu/files-reg.c:1277): Can't lookup mount=410 for fd=-3 path=/bin/busybox (00.170987) Error (criu/cr-dump.c:1246): Collect mappings (pid: 1637) failed with -1 We have not seen this only in Travis, but also multiple CRIU users reported that bug already. Currently we have to tell them to downgrade the kernel. I also able to reproduce it with linux-image-5.3.0-24-generic. Staying on the 4.18.0 kernel series does not show this error. 4.18.0-25-generic works without problems. See also https://github.com/checkpoint-restore/criu/issues/860 One of the possible explanations from our side include: "Looks like we have the same as for st_dev now with mnt_id, that is bad, because we can't find on which mount to open the file if kernel hides these information from us." Running on the upstream 5.5.0-rc1 kernel does not show this error. --- ProblemType: Bug AlsaDevices: total 0 crw-rw 1 root audio 116, 1 Jan 7 18:52 seq crw-rw 1 root audio 116, 33 Jan 7 18:52 timer AplayDevices: Error: [Errno 2] No such file or directory: 'aplay': 'aplay' ApportVersion: 2.20.11-0ubuntu8.2 Architecture: amd64 ArecordDevices: Error: [Errno 2] No such file or directory: 'arecord': 'arecord' AudioDevicesInUse: Error: command ['fuser', '-v', '/dev/snd/seq', '/dev/snd/timer'] failed with exit code 1: CRDA: N/A DistroRelease: Ubuntu 19.10 IwConfig: Error: [Errno 2] No such file or directory: 'iwconfig': 'iwconfig' Lsusb: Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub MachineType: DigitalOcean Droplet Package: linux (not installed) PciMultimedia: ProcFB: ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.3.0-26-generic root=PARTUUID=5b57f3f9-086a-4a7d-ae78-efdee8842586 ro console=tty1 console=ttyS0 ProcVersionSignature: Ubuntu 5.3.0-26.28-generic 5.3.13 RelatedPackageVersions: linux-restricted-modules-5.3.0-26-generic N/A linux-backports-modules-5.3.0-26-generic N/A linux-firmwareN/A RfKill: Error: [Errno 2] No such file or directory: 'rfkill': 'rfkill' Tags: eoan uec-images Uname: Linux 5.3.0-26-generic x86_64 UpgradeStatus: No upgrade log present (probably fresh install) UserGroups: _MarkForUpload: True dmi.bios.date: 12/12/2017 dmi.bios.vendor: DigitalOcean dmi.bios.version: 20171212 dmi.chassis.type: 1 dmi.chassis.vendor: Bochs dmi.modalias: dmi:bvnDigitalOcean:bvr20171212:bd12/12/2017:svnDigitalOcean:pnDroplet:pvr20171212:cvnBochs:ct1:cvr: dmi.product.family: DigitalOcean_Droplet dmi.product.name: Droplet dmi.product.version: 20171212 dmi.sys.vendor: DigitalOcean To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1857257/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1876645] Re: Unable to handle kernel pointer dereference in virtual kernel address space on Eoan
** Changed in: linux (Ubuntu) Status: Confirmed => In Progress ** Changed in: linux (Ubuntu Eoan) Status: Confirmed => In Progress ** Changed in: linux (Ubuntu Focal) Status: New => In Progress ** Changed in: linux (Ubuntu) Assignee: (unassigned) => Christian Brauner (cbrauner) ** Changed in: linux (Ubuntu Eoan) Assignee: (unassigned) => Christian Brauner (cbrauner) ** Changed in: linux (Ubuntu Focal) Assignee: (unassigned) => Christian Brauner (cbrauner) -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1876645 Title: Unable to handle kernel pointer dereference in virtual kernel address space on Eoan Status in ubuntu-kernel-tests: New Status in linux package in Ubuntu: In Progress Status in linux source package in Eoan: In Progress Status in linux source package in Focal: In Progress Bug description: Issue spotted on Eoan zVM / LPAR It looks like this happens when running the ubunut_fan_smoke_test (jenkins job hang with this one) [ 1225.137764] docker0: port 1(veth2fda0c6) entered blocking state [ 1225.137767] docker0: port 1(veth2fda0c6) entered disabled state [ 1225.138023] device veth2fda0c6 entered promiscuous mode [ 1225.148523] Unable to handle kernel pointer dereference in virtual kernel address space [ 1225.148529] Failing address: 6f766c5f646f5000 TEID: 6f766c5f646f5803 [ 1225.148531] Fault in home space mode while using kernel ASCE. [ 1225.148533] AS:00070d94c007 R3:0024 [ 1225.148575] Oops: 0038 ilc:3 [#1] SMP [ 1225.148578] Modules linked in: veth xt_nat vxlan ip6_udp_tunnel udp_tunnel nf_conntrack_netlink xfrm_user xfrm_algo xt_addrtype br_netfilter unix_diag sctp cuse vhost_net tap vhost_vsock vmw_vsock_virtio_transport_common vhost vsock dccp_ipv4 dccp algif_rng aegis128 aegis128l aegis256 morus1280 morus640 algif_aead anubis fcrypt khazad seed sm4_generic tea md4 michael_mic nhpoly1305 poly1305_generic rmd128 rmd160 rmd256 rmd320 sha3_generic sm3_generic streebog_generic tgr192 wp512 xxhash_generic algif_hash blowfish_generic blowfish_common cast5_generic salsa20_generic chacha_generic camellia_generic cast6_generic cast_common serpent_generic twofish_generic twofish_common algif_skcipher af_alg xt_conntrack ipt_REJECT nf_reject_ipv4 ip6table_mangle ip6table_nat nf_tables nfnetlink ip6table_filter ip6_tables iptable_mangle xt_CHECKSUM iptable_nat xt_MASQUERADE xt_tcpudp bridge iptable_filter bpfilter aufs overlay 8021q garp stp mrp llc openvswitch nsh nf_conncount nf_nat nf_conntrack [ 1225.148622] nf_defrag_ipv6 nf_defrag_ipv4 binfmt_misc zfs(PO) zunicode(PO) zavl(PO) icp(PO) zlua(PO) zcommon(PO) znvpair(PO) spl(O) genwqe_card crc_itu_t chsc_sch eadm_sch ctcm fsm vfio_ccw vfio_mdev mdev vfio_iommu_type1 vfio sch_fq_codel nfsd auth_rpcgss nfs_acl lockd grace sunrpc ip_tables x_tables btrfs zstd_compress zlib_deflate raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c raid1 raid0 linear dm_service_time mlx4_ib ib_uverbs mlx4_en ptp ib_core pps_core pkey zcrypt crc32_vx_s390 ghash_s390 prng aes_s390 des_s390 qeth_l2 des_generic sha512_s390 sha256_s390 sha1_s390 sha_common mlx4_core zfcp scsi_transport_fc qeth qdio ccwgroup dasd_eckd_mod dasd_mod scsi_dh_emc scsi_dh_rdac scsi_dh_alua dm_multipath [ 1225.148711] CPU: 4 PID: 161930 Comm: dockerd Tainted: P O 5.3.0-52-generic #46-Ubuntu [ 1225.148714] Hardware name: IBM 2964 N63 400 (LPAR) [ 1225.148716] Krnl PSW : 0704d0018000 03ff808e972a (ovl_open_realfile+0x4a/0x148 [overlay]) [ 1225.148734]R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:1 PM:0 RI:0 EA:3 [ 1225.148736] Krnl GPRS: 0064 6f766c5f646f5f6d 0007a14ac300 0003a5df6600 [ 1225.148738]8000 0001 0003 000372e45278 [ 1225.148740]03ff808ea508 000304048000 0005c7f32b68 00064a2ab900 [ 1225.148742]0003a5df6600 03ff808f31d8 03ff808e971a 03e009c0faf8 [ 1225.148749] Krnl Code: 03ff808e971a: a59a0404 oilh%r9,1028 03ff808e971e: e310f0c4 lg %r1,192(%r15) #03ff808e9724: e31010680004 lg %r1,104(%r1) >03ff808e972a: e3101064 lg %r1,96(%r1) 03ff808e9730: b9040082 lgr %r8,%r2 03ff808e9734: c21c6a656a62 cgfi %r1,1785031266 03ff808e973a: b9140039 lgfr%r3,%r9 03ff808e973e: e3100344 lg %r1,832 [ 1225.148766] Call Trace: [ 1225.148769] ([<>] 0x0) [ 1225.148774] [<03ff808ea582
[Kernel-packages] [Bug 1876645] Re: Unable to handle kernel pointer dereference in virtual kernel address space on Eoan
Fix here: https://lists.ubuntu.com/archives/kernel-team/2020-May/109617.html -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1876645 Title: Unable to handle kernel pointer dereference in virtual kernel address space on Eoan Status in ubuntu-kernel-tests: New Status in linux package in Ubuntu: In Progress Status in linux source package in Eoan: In Progress Status in linux source package in Focal: In Progress Bug description: Issue spotted on Eoan zVM / LPAR It looks like this happens when running the ubunut_fan_smoke_test (jenkins job hang with this one) [ 1225.137764] docker0: port 1(veth2fda0c6) entered blocking state [ 1225.137767] docker0: port 1(veth2fda0c6) entered disabled state [ 1225.138023] device veth2fda0c6 entered promiscuous mode [ 1225.148523] Unable to handle kernel pointer dereference in virtual kernel address space [ 1225.148529] Failing address: 6f766c5f646f5000 TEID: 6f766c5f646f5803 [ 1225.148531] Fault in home space mode while using kernel ASCE. [ 1225.148533] AS:00070d94c007 R3:0024 [ 1225.148575] Oops: 0038 ilc:3 [#1] SMP [ 1225.148578] Modules linked in: veth xt_nat vxlan ip6_udp_tunnel udp_tunnel nf_conntrack_netlink xfrm_user xfrm_algo xt_addrtype br_netfilter unix_diag sctp cuse vhost_net tap vhost_vsock vmw_vsock_virtio_transport_common vhost vsock dccp_ipv4 dccp algif_rng aegis128 aegis128l aegis256 morus1280 morus640 algif_aead anubis fcrypt khazad seed sm4_generic tea md4 michael_mic nhpoly1305 poly1305_generic rmd128 rmd160 rmd256 rmd320 sha3_generic sm3_generic streebog_generic tgr192 wp512 xxhash_generic algif_hash blowfish_generic blowfish_common cast5_generic salsa20_generic chacha_generic camellia_generic cast6_generic cast_common serpent_generic twofish_generic twofish_common algif_skcipher af_alg xt_conntrack ipt_REJECT nf_reject_ipv4 ip6table_mangle ip6table_nat nf_tables nfnetlink ip6table_filter ip6_tables iptable_mangle xt_CHECKSUM iptable_nat xt_MASQUERADE xt_tcpudp bridge iptable_filter bpfilter aufs overlay 8021q garp stp mrp llc openvswitch nsh nf_conncount nf_nat nf_conntrack [ 1225.148622] nf_defrag_ipv6 nf_defrag_ipv4 binfmt_misc zfs(PO) zunicode(PO) zavl(PO) icp(PO) zlua(PO) zcommon(PO) znvpair(PO) spl(O) genwqe_card crc_itu_t chsc_sch eadm_sch ctcm fsm vfio_ccw vfio_mdev mdev vfio_iommu_type1 vfio sch_fq_codel nfsd auth_rpcgss nfs_acl lockd grace sunrpc ip_tables x_tables btrfs zstd_compress zlib_deflate raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c raid1 raid0 linear dm_service_time mlx4_ib ib_uverbs mlx4_en ptp ib_core pps_core pkey zcrypt crc32_vx_s390 ghash_s390 prng aes_s390 des_s390 qeth_l2 des_generic sha512_s390 sha256_s390 sha1_s390 sha_common mlx4_core zfcp scsi_transport_fc qeth qdio ccwgroup dasd_eckd_mod dasd_mod scsi_dh_emc scsi_dh_rdac scsi_dh_alua dm_multipath [ 1225.148711] CPU: 4 PID: 161930 Comm: dockerd Tainted: P O 5.3.0-52-generic #46-Ubuntu [ 1225.148714] Hardware name: IBM 2964 N63 400 (LPAR) [ 1225.148716] Krnl PSW : 0704d0018000 03ff808e972a (ovl_open_realfile+0x4a/0x148 [overlay]) [ 1225.148734]R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:1 PM:0 RI:0 EA:3 [ 1225.148736] Krnl GPRS: 0064 6f766c5f646f5f6d 0007a14ac300 0003a5df6600 [ 1225.148738]8000 0001 0003 000372e45278 [ 1225.148740]03ff808ea508 000304048000 0005c7f32b68 00064a2ab900 [ 1225.148742]0003a5df6600 03ff808f31d8 03ff808e971a 03e009c0faf8 [ 1225.148749] Krnl Code: 03ff808e971a: a59a0404 oilh%r9,1028 03ff808e971e: e310f0c4 lg %r1,192(%r15) #03ff808e9724: e31010680004 lg %r1,104(%r1) >03ff808e972a: e3101064 lg %r1,96(%r1) 03ff808e9730: b9040082 lgr %r8,%r2 03ff808e9734: c21c6a656a62 cgfi %r1,1785031266 03ff808e973a: b9140039 lgfr%r3,%r9 03ff808e973e: e3100344 lg %r1,832 [ 1225.148766] Call Trace: [ 1225.148769] ([<>] 0x0) [ 1225.148774] [<03ff808ea582>] ovl_open+0x7a/0xc0 [overlay] [ 1225.148780] [<00070cbf2c04>] do_dentry_open+0x1fc/0x3b0 [ 1225.148784] [<00070cc0afd2>] do_last+0x1ba/0x970 [ 1225.148786] [<00070cc0b80e>] path_openat+0x86/0x2b8 [ 1225.148788] [<00070cc0cea4>] do_filp_open+0x7c/0xf8 [ 1225.148791] [<00070cbf4b5a>] do_sys_open+0x19a/0x2c8 [ 1225.148798] [<00070d1ebca8>] system_call+0xdc/0x2c8 [ 1225.148800] Last Breaking-Event-Address: [
[Kernel-packages] [Bug 1857257] Re: linux-image-5.0.0-35-generic breaks checkpointing of container
Yeah, that patch is buggy and I think this might've been my fault actually. The fix should be: diff --git a/fs/overlayfs/file.c b/fs/overlayfs/file.c index 9d16fff5342a..fbec523a67c9 100644 --- a/fs/overlayfs/file.c +++ b/fs/overlayfs/file.c @@ -42,6 +42,7 @@ static struct file *ovl_open_realfile(const struct file *file, int flags = file->f_flags | O_NOATIME | FMODE_NONOTIFY; old_cred = ovl_override_creds(inode->i_sb); + ovl_path_real(file->f_path.dentry, ); if (realpath.dentry->d_sb->s_magic == SHIFTFS_MAGIC) realfile = open_with_fake_path(, flags, realinode, current_cred()); -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1857257 Title: linux-image-5.0.0-35-generic breaks checkpointing of container Status in linux package in Ubuntu: In Progress Status in linux source package in Eoan: Fix Committed Status in linux source package in Focal: Fix Committed Bug description: Trying to checkpoint a container (docker/podman) on 18.04 fails starting with linux-image-5.0.0-35-generic. We (CRIU upstream) see this in Travis starting a few weeks ago. Manually testing it locally shows that linux-image-5.0.0-32-generic still works and linux- image-5.0.0-35-generic does not longer work. It seems to be overlayfs related, at least that is what we believe. The CRIU error message we see is: (00.170944) Error (criu/files-reg.c:1277): Can't lookup mount=410 for fd=-3 path=/bin/busybox (00.170987) Error (criu/cr-dump.c:1246): Collect mappings (pid: 1637) failed with -1 We have not seen this only in Travis, but also multiple CRIU users reported that bug already. Currently we have to tell them to downgrade the kernel. I also able to reproduce it with linux-image-5.3.0-24-generic. Staying on the 4.18.0 kernel series does not show this error. 4.18.0-25-generic works without problems. See also https://github.com/checkpoint-restore/criu/issues/860 One of the possible explanations from our side include: "Looks like we have the same as for st_dev now with mnt_id, that is bad, because we can't find on which mount to open the file if kernel hides these information from us." Running on the upstream 5.5.0-rc1 kernel does not show this error. --- ProblemType: Bug AlsaDevices: total 0 crw-rw 1 root audio 116, 1 Jan 7 18:52 seq crw-rw 1 root audio 116, 33 Jan 7 18:52 timer AplayDevices: Error: [Errno 2] No such file or directory: 'aplay': 'aplay' ApportVersion: 2.20.11-0ubuntu8.2 Architecture: amd64 ArecordDevices: Error: [Errno 2] No such file or directory: 'arecord': 'arecord' AudioDevicesInUse: Error: command ['fuser', '-v', '/dev/snd/seq', '/dev/snd/timer'] failed with exit code 1: CRDA: N/A DistroRelease: Ubuntu 19.10 IwConfig: Error: [Errno 2] No such file or directory: 'iwconfig': 'iwconfig' Lsusb: Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub MachineType: DigitalOcean Droplet Package: linux (not installed) PciMultimedia: ProcFB: ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.3.0-26-generic root=PARTUUID=5b57f3f9-086a-4a7d-ae78-efdee8842586 ro console=tty1 console=ttyS0 ProcVersionSignature: Ubuntu 5.3.0-26.28-generic 5.3.13 RelatedPackageVersions: linux-restricted-modules-5.3.0-26-generic N/A linux-backports-modules-5.3.0-26-generic N/A linux-firmwareN/A RfKill: Error: [Errno 2] No such file or directory: 'rfkill': 'rfkill' Tags: eoan uec-images Uname: Linux 5.3.0-26-generic x86_64 UpgradeStatus: No upgrade log present (probably fresh install) UserGroups: _MarkForUpload: True dmi.bios.date: 12/12/2017 dmi.bios.vendor: DigitalOcean dmi.bios.version: 20171212 dmi.chassis.type: 1 dmi.chassis.vendor: Bochs dmi.modalias: dmi:bvnDigitalOcean:bvr20171212:bd12/12/2017:svnDigitalOcean:pnDroplet:pvr20171212:cvnBochs:ct1:cvr: dmi.product.family: DigitalOcean_Droplet dmi.product.name: Droplet dmi.product.version: 20171212 dmi.sys.vendor: DigitalOcean To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1857257/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1872757] Re: shiftfs: O_TMPFILE reports ESTALE
** Tags removed: verification-needed-eoan
** Tags added: verification-done-eoan
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1872757
Title:
shiftfs: O_TMPFILE reports ESTALE
Status in linux package in Ubuntu:
In Progress
Status in linux source package in Eoan:
Fix Committed
Status in linux source package in Focal:
Fix Committed
Bug description:
SRU Justification
Impact: Christian Kellner reported that creating temporary files via
O_TMPFILE shiftfs reports ESTALE. This can be reproduced via:
import tempfile
import os
def test():
with tempfile.TemporaryFile() as fd:
fd.write("data".encode('utf-8'))
# re-open the file to get a read-only file descriptor
return open(f"/proc/self/fd/{fd.fileno()}", "r")
def main():
fd = test()
fd.close()
if __name__ == "__main__":
main()
a similar issue was reported here:
https://github.com/systemd/systemd/issues/14861
Fix: Our revalidate methods were very opinionated about whether or not
a dentry was valid when we really should've just let the underlay tell
us what's what. This has led to bugs where a ESTALE was returned for
e.g. temporary files that were created and directly re-opened
afterwards through /proc//fd/. When a file is
re-opened through /proc//fd/ LOOKUP_JUMP is set and the vfs
will revalidate via d_weak_revalidate(). Since the file has been
unhashed or even already gone negative we'd fail the open when we
should've succeeded.
I had also foolishly provided a .tmpfile method which so far only has
caused us trouble. If we really need this then we can reimplement it
properly but I doubt it. Remove it for now.
Regression Potential: Limited to shiftfs.
Test Case: Build a kernel with fix applied and run above reproducer.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1872757/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1857257] Re: linux-image-5.0.0-35-generic breaks checkpointing of container
** Changed in: linux (Ubuntu) Status: Confirmed => In Progress -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1857257 Title: linux-image-5.0.0-35-generic breaks checkpointing of container Status in linux package in Ubuntu: In Progress Bug description: Trying to checkpoint a container (docker/podman) on 18.04 fails starting with linux-image-5.0.0-35-generic. We (CRIU upstream) see this in Travis starting a few weeks ago. Manually testing it locally shows that linux-image-5.0.0-32-generic still works and linux- image-5.0.0-35-generic does not longer work. It seems to be overlayfs related, at least that is what we believe. The CRIU error message we see is: (00.170944) Error (criu/files-reg.c:1277): Can't lookup mount=410 for fd=-3 path=/bin/busybox (00.170987) Error (criu/cr-dump.c:1246): Collect mappings (pid: 1637) failed with -1 We have not seen this only in Travis, but also multiple CRIU users reported that bug already. Currently we have to tell them to downgrade the kernel. I also able to reproduce it with linux-image-5.3.0-24-generic. Staying on the 4.18.0 kernel series does not show this error. 4.18.0-25-generic works without problems. See also https://github.com/checkpoint-restore/criu/issues/860 One of the possible explanations from our side include: "Looks like we have the same as for st_dev now with mnt_id, that is bad, because we can't find on which mount to open the file if kernel hides these information from us." Running on the upstream 5.5.0-rc1 kernel does not show this error. --- ProblemType: Bug AlsaDevices: total 0 crw-rw 1 root audio 116, 1 Jan 7 18:52 seq crw-rw 1 root audio 116, 33 Jan 7 18:52 timer AplayDevices: Error: [Errno 2] No such file or directory: 'aplay': 'aplay' ApportVersion: 2.20.11-0ubuntu8.2 Architecture: amd64 ArecordDevices: Error: [Errno 2] No such file or directory: 'arecord': 'arecord' AudioDevicesInUse: Error: command ['fuser', '-v', '/dev/snd/seq', '/dev/snd/timer'] failed with exit code 1: CRDA: N/A DistroRelease: Ubuntu 19.10 IwConfig: Error: [Errno 2] No such file or directory: 'iwconfig': 'iwconfig' Lsusb: Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub MachineType: DigitalOcean Droplet Package: linux (not installed) PciMultimedia: ProcFB: ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.3.0-26-generic root=PARTUUID=5b57f3f9-086a-4a7d-ae78-efdee8842586 ro console=tty1 console=ttyS0 ProcVersionSignature: Ubuntu 5.3.0-26.28-generic 5.3.13 RelatedPackageVersions: linux-restricted-modules-5.3.0-26-generic N/A linux-backports-modules-5.3.0-26-generic N/A linux-firmwareN/A RfKill: Error: [Errno 2] No such file or directory: 'rfkill': 'rfkill' Tags: eoan uec-images Uname: Linux 5.3.0-26-generic x86_64 UpgradeStatus: No upgrade log present (probably fresh install) UserGroups: _MarkForUpload: True dmi.bios.date: 12/12/2017 dmi.bios.vendor: DigitalOcean dmi.bios.version: 20171212 dmi.chassis.type: 1 dmi.chassis.vendor: Bochs dmi.modalias: dmi:bvnDigitalOcean:bvr20171212:bd12/12/2017:svnDigitalOcean:pnDroplet:pvr20171212:cvnBochs:ct1:cvr: dmi.product.family: DigitalOcean_Droplet dmi.product.name: Droplet dmi.product.version: 20171212 dmi.sys.vendor: DigitalOcean To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1857257/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1872757] Re: shiftfs: O_TMPFILE reports ESTALE
** Description changed:
SRU Justification
Impact: Christian Kellner reported that creating temporary files via
O_TMPFILE shiftfs reports ESTALE. This can be reproduced via:
import tempfile
import os
-
def test():
- with tempfile.TemporaryFile() as fd:
- fd.write("data".encode('utf-8'))
- # re-open the file to get a read-only file descriptor
- return open(f"/proc/self/fd/{fd.fileno()}", "r")
-
+ with tempfile.TemporaryFile() as fd:
+ fd.write("data".encode('utf-8'))
+ # re-open the file to get a read-only file descriptor
+ return open(f"/proc/self/fd/{fd.fileno()}", "r")
def main():
-fd = test()
-fd.close()
-
+ fd = test()
+ fd.close()
if __name__ == "__main__":
- main()
+ main()
a similar issue was reported here:
https://github.com/systemd/systemd/issues/14861
+ Fix: Our revalidate methods were very opinionated about whether or not a
+ dentry was valid when we really should've just let the underlay tell us
+ what's what. This has led to bugs where a ESTALE was returned for e.g.
+ temporary files that were created and directly re-opened afterwards
+ through /proc//fd/. When a file is re-opened
+ through /proc//fd/ LOOKUP_JUMP is set and the vfs will
+ revalidate via d_weak_revalidate(). Since the file has been unhashed or
+ even already gone negative we'd fail the open when we should've
+ succeeded.
+
+ I had also foolishly provided a .tmpfile method which so far only has
+ caused us trouble. If we really need this then we can reimplement it
+ properly but I doubt it. Remove it for now.
+
Regression Potential: Limited to shiftfs.
Test Case: Build a kernel with fix applied and run above reproducer.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1872757
Title:
shiftfs: O_TMPFILE reports ESTALE
Status in linux package in Ubuntu:
In Progress
Bug description:
SRU Justification
Impact: Christian Kellner reported that creating temporary files via
O_TMPFILE shiftfs reports ESTALE. This can be reproduced via:
import tempfile
import os
def test():
with tempfile.TemporaryFile() as fd:
fd.write("data".encode('utf-8'))
# re-open the file to get a read-only file descriptor
return open(f"/proc/self/fd/{fd.fileno()}", "r")
def main():
fd = test()
fd.close()
if __name__ == "__main__":
main()
a similar issue was reported here:
https://github.com/systemd/systemd/issues/14861
Fix: Our revalidate methods were very opinionated about whether or not
a dentry was valid when we really should've just let the underlay tell
us what's what. This has led to bugs where a ESTALE was returned for
e.g. temporary files that were created and directly re-opened
afterwards through /proc//fd/. When a file is
re-opened through /proc//fd/ LOOKUP_JUMP is set and the vfs
will revalidate via d_weak_revalidate(). Since the file has been
unhashed or even already gone negative we'd fail the open when we
should've succeeded.
I had also foolishly provided a .tmpfile method which so far only has
caused us trouble. If we really need this then we can reimplement it
properly but I doubt it. Remove it for now.
Regression Potential: Limited to shiftfs.
Test Case: Build a kernel with fix applied and run above reproducer.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1872757/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1872757] [NEW] shiftfs: O_TMPFILE reports ESTALE
Public bug reported:
SRU Justification
Impact: Christian Kellner reported that creating temporary files via
O_TMPFILE shiftfs reports ESTALE. This can be reproduced via:
import tempfile
import os
def test():
with tempfile.TemporaryFile() as fd:
fd.write("data".encode('utf-8'))
# re-open the file to get a read-only file descriptor
return open(f"/proc/self/fd/{fd.fileno()}", "r")
def main():
fd = test()
fd.close()
if __name__ == "__main__":
main()
a similar issue was reported here:
https://github.com/systemd/systemd/issues/14861
Regression Potential: Limited to shiftfs.
Test Case: Build a kernel with fix applied and run above reproducer.
** Affects: linux (Ubuntu)
Importance: Undecided
Assignee: Christian Brauner (cbrauner)
Status: In Progress
** Changed in: linux (Ubuntu)
Assignee: (unassigned) => Christian Brauner (cbrauner)
** Changed in: linux (Ubuntu)
Status: New => Confirmed
** Changed in: linux (Ubuntu)
Status: Confirmed => In Progress
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1872757
Title:
shiftfs: O_TMPFILE reports ESTALE
Status in linux package in Ubuntu:
In Progress
Bug description:
SRU Justification
Impact: Christian Kellner reported that creating temporary files via
O_TMPFILE shiftfs reports ESTALE. This can be reproduced via:
import tempfile
import os
def test():
with tempfile.TemporaryFile() as fd:
fd.write("data".encode('utf-8'))
# re-open the file to get a read-only file descriptor
return open(f"/proc/self/fd/{fd.fileno()}", "r")
def main():
fd = test()
fd.close()
if __name__ == "__main__":
main()
a similar issue was reported here:
https://github.com/systemd/systemd/issues/14861
Regression Potential: Limited to shiftfs.
Test Case: Build a kernel with fix applied and run above reproducer.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1872757/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1872094] Re: shiftfs: broken shiftfs nesting
This should preferably be backported to all LTS kernels that support shiftfs. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1872094 Title: shiftfs: broken shiftfs nesting Status in linux package in Ubuntu: In Progress Bug description: SRU Justification Impact: When nested containers use shiftfs and they have different id mappings the nested container lacks privileges to create any files in its root filesystem unless the directory in question is very permissive. This prevents nested containers from being usable. Here is a reproducer as given by Stéphane: Reproducer: - lxc init images:ubuntu/bionic b1 -c security.nesting=true - Confirm b1 uses shiftfs and uses the default map root@b1:~# cat /proc/self/uid_map 0100 10 root@b1:~# grep shiftfs /proc/self/mountinfo 3702 2266 0:92 / / rw,relatime - shiftfs /var/lib/lxd/storage-pools/default/containers/b1/rootfs rw,passthrough=3 - Install LXD snap in there - snap set lxd shiftfs.enable=true - systemctl reload snap.lxd.daemon - lxd init --auto - lxc launch images:alpine/edge a1 - Confirm that a1 uses a different map than b1 - Confirm that a1 uses shiftfs - touch /etc/a should fail with EACCES Fix: Instead of recording the credentials of the process that created the innermost shiftfs mount we need to record the credentials of the lowers creator of the first shiftfs mark mount since we always refer back to the lowers mount to get around vfs layering restrictions. Regression Potential: Limited to shiftfs. Test Case: Built a kernel with the mentioned fix and ran the reproducer. The issue was not reproducible. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1872094/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1872094] [NEW] shiftfs: broken shiftfs nesting
Public bug reported: SRU Justification Impact: When nested containers use shiftfs and they have different id mappings the nested container lacks privileges to create any files in its root filesystem unless the directory in question is very permissive. This prevents nested containers from being usable. Here is a reproducer as given by Stéphane: Reproducer: - lxc init images:ubuntu/bionic b1 -c security.nesting=true - Confirm b1 uses shiftfs and uses the default map root@b1:~# cat /proc/self/uid_map 0100 10 root@b1:~# grep shiftfs /proc/self/mountinfo 3702 2266 0:92 / / rw,relatime - shiftfs /var/lib/lxd/storage-pools/default/containers/b1/rootfs rw,passthrough=3 - Install LXD snap in there - snap set lxd shiftfs.enable=true - systemctl reload snap.lxd.daemon - lxd init --auto - lxc launch images:alpine/edge a1 - Confirm that a1 uses a different map than b1 - Confirm that a1 uses shiftfs - touch /etc/a should fail with EACCES Fix: Instead of recording the credentials of the process that created the innermost shiftfs mount we need to record the credentials of the lowers creator of the first shiftfs mark mount since we always refer back to the lowers mount to get around vfs layering restrictions. Regression Potential: Limited to shiftfs. Test Case: Built a kernel with the mentioned fix and ran the reproducer. The issue was not reproducible. ** Affects: linux (Ubuntu) Importance: Undecided Assignee: Christian Brauner (cbrauner) Status: In Progress ** Changed in: linux (Ubuntu) Assignee: (unassigned) => Christian Brauner (cbrauner) ** Changed in: linux (Ubuntu) Status: New => In Progress -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1872094 Title: shiftfs: broken shiftfs nesting Status in linux package in Ubuntu: In Progress Bug description: SRU Justification Impact: When nested containers use shiftfs and they have different id mappings the nested container lacks privileges to create any files in its root filesystem unless the directory in question is very permissive. This prevents nested containers from being usable. Here is a reproducer as given by Stéphane: Reproducer: - lxc init images:ubuntu/bionic b1 -c security.nesting=true - Confirm b1 uses shiftfs and uses the default map root@b1:~# cat /proc/self/uid_map 0100 10 root@b1:~# grep shiftfs /proc/self/mountinfo 3702 2266 0:92 / / rw,relatime - shiftfs /var/lib/lxd/storage-pools/default/containers/b1/rootfs rw,passthrough=3 - Install LXD snap in there - snap set lxd shiftfs.enable=true - systemctl reload snap.lxd.daemon - lxd init --auto - lxc launch images:alpine/edge a1 - Confirm that a1 uses a different map than b1 - Confirm that a1 uses shiftfs - touch /etc/a should fail with EACCES Fix: Instead of recording the credentials of the process that created the innermost shiftfs mount we need to record the credentials of the lowers creator of the first shiftfs mark mount since we always refer back to the lowers mount to get around vfs layering restrictions. Regression Potential: Limited to shiftfs. Test Case: Built a kernel with the mentioned fix and ran the reproducer. The issue was not reproducible. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1872094/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1872094] Re: shiftfs: broken shiftfs nesting
See https://github.com/brauner/ubuntu-unstable/commits/2020-04-10/shiftfs_nesting for fix. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1872094 Title: shiftfs: broken shiftfs nesting Status in linux package in Ubuntu: In Progress Bug description: SRU Justification Impact: When nested containers use shiftfs and they have different id mappings the nested container lacks privileges to create any files in its root filesystem unless the directory in question is very permissive. This prevents nested containers from being usable. Here is a reproducer as given by Stéphane: Reproducer: - lxc init images:ubuntu/bionic b1 -c security.nesting=true - Confirm b1 uses shiftfs and uses the default map root@b1:~# cat /proc/self/uid_map 0100 10 root@b1:~# grep shiftfs /proc/self/mountinfo 3702 2266 0:92 / / rw,relatime - shiftfs /var/lib/lxd/storage-pools/default/containers/b1/rootfs rw,passthrough=3 - Install LXD snap in there - snap set lxd shiftfs.enable=true - systemctl reload snap.lxd.daemon - lxd init --auto - lxc launch images:alpine/edge a1 - Confirm that a1 uses a different map than b1 - Confirm that a1 uses shiftfs - touch /etc/a should fail with EACCES Fix: Instead of recording the credentials of the process that created the innermost shiftfs mount we need to record the credentials of the lowers creator of the first shiftfs mark mount since we always refer back to the lowers mount to get around vfs layering restrictions. Regression Potential: Limited to shiftfs. Test Case: Built a kernel with the mentioned fix and ran the reproducer. The issue was not reproducible. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1872094/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
Re: [Kernel-packages] [Bug 1865359] Re: sysfs: incorrect network device permissions on network namespace change
On March 27, 2020 10:57:17 PM GMT+01:00, Seth Forshee wrote: >Applied the patches from linux-next, plus one additional fix I saw, >"sysfs: fix static inline declaration of sysfs_groups_change_owner()". >@Christian, please let me know if there are any other fixes we need to >grab. > >** Changed in: linux (Ubuntu Focal) > Status: In Progress => Fix Committed Nope, no additional fixes. This is great, thank you for doing this! -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1865359 Title: sysfs: incorrect network device permissions on network namespace change Status in linux package in Ubuntu: Fix Committed Status in linux source package in Focal: Fix Committed Bug description: SRU Justification Impact: patchsets.) We have been struggling with a bug surrounding the ownership of network device sysfs files when moving network devices between network namespaces owned by different user namespaces reported by multiple users. Currently, when moving network devices between network namespaces the ownership of the corresponding sysfs entries is not changed. This leads to problems when tools try to operate on the corresponding sysfs files. I also causes a bug when creating a network device in a network namespaces owned by a user namespace and moving that network device back to the host network namespaces. Because when a network device is created in a network namespaces it will be owned by the root user of the user namespace and all its associated sysfs files will also be owned by the root user of the corresponding user namespace. If such a network device has to be moved back to the host network namespace the permissions will still be set to the root user of the owning user namespaces of the originating network namespace. This means unprivileged users can e.g. re-trigger uevents for such incorrectly owned devices on the host or in other network namespaces. They can also modify the settings of the device itself through sysfs when they wouldn't be able to do the same through netlink. Both of these things are unwanted. For example, quite a few workloads will create network devices in the host network namespace. Other tools will then proceed to move such devices between network namespaces owner by other user namespaces. While the ownership of the device itself is updated in net/core/net-sysfs.c:dev_change_net_namespace() the corresponding sysfs entry for the device is not. Below you'll find that moving a network device (here a veth device) from a network namespace into another network namespaces owned by a different user namespace with a different id mapping. As you can see the permissions are wrong even though it is owned by the userns root user after it has been moved and can be interacted with through netlink: drwxr-xr-x 5 nobody nobody0 Jan 25 18:08 . drwxr-xr-x 9 nobody nobody0 Jan 25 18:08 .. -r--r--r-- 1 nobody nobody 4096 Jan 25 18:09 addr_assign_type -r--r--r-- 1 nobody nobody 4096 Jan 25 18:09 addr_len -r--r--r-- 1 nobody nobody 4096 Jan 25 18:09 address -r--r--r-- 1 nobody nobody 4096 Jan 25 18:09 broadcast -rw-r--r-- 1 nobody nobody 4096 Jan 25 18:09 carrier -r--r--r-- 1 nobody nobody 4096 Jan 25 18:09 carrier_changes -r--r--r-- 1 nobody nobody 4096 Jan 25 18:09 carrier_down_count -r--r--r-- 1 nobody nobody 4096 Jan 25 18:09 carrier_up_count -r--r--r-- 1 nobody nobody 4096 Jan 25 18:09 dev_id -r--r--r-- 1 nobody nobody 4096 Jan 25 18:09 dev_port -r--r--r-- 1 nobody nobody 4096 Jan 25 18:09 dormant -r--r--r-- 1 nobody nobody 4096 Jan 25 18:09 duplex -rw-r--r-- 1 nobody nobody 4096 Jan 25 18:09 flags -rw-r--r-- 1 nobody nobody 4096 Jan 25 18:09 gro_flush_timeout -rw-r--r-- 1 nobody nobody 4096 Jan 25 18:09 ifalias -r--r--r-- 1 nobody nobody 4096 Jan 25 18:09 ifindex -r--r--r-- 1 nobody nobody 4096 Jan 25 18:09 iflink -r--r--r-- 1 nobody nobody 4096 Jan 25 18:09 link_mode -rw-r--r-- 1 nobody nobody 4096 Jan 25 18:09 mtu -r--r--r-- 1 nobody nobody 4096 Jan 25 18:09 name_assign_type -rw-r--r-- 1 nobody nobody 4096 Jan 25 18:09 netdev_group -r--r--r-- 1 nobody nobody 4096 Jan 25 18:09 operstate -r--r--r-- 1 nobody nobody 4096 Jan 25 18:09 phys_port_id -r--r--r-- 1 nobody nobody 4096 Jan 25 18:09 phys_port_name -r--r--r-- 1 nobody nobody 4096 Jan 25 18:09 phys_switch_id drwxr-xr-x 2 nobody nobody0 Jan 25 18:09 power -rw-r--r-- 1 nobody nobody 4096 Jan 25 18:09 proto_down drwxr-xr-x 4 nobody nobody0 Jan 25 18:09 queues -r--r--r-- 1 nobody nobody 4096 Jan 25 18:09 speed drwxr-xr-x 2 nobody nobody0 Jan 25 18:09 statistics lrwxrwxrwx 1 nobody nobody0 Jan 25 18:08 subsystem -> ../../../../class/net -rw-r--r-- 1 nobody nobody 4096 Jan 25 18:09 tx_queue_len -r--r--r-- 1 nobody nobody 4096 Jan 25 18:09 type -rw-r--r-- 1 nobody
[Kernel-packages] [Bug 1860041] Re: shiftfs: prevent lower dentries from going negative during unlink
** Tags removed: verification-needed-eoan
** Tags added: verification-done-eoan
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1860041
Title:
shiftfs: prevent lower dentries from going negative during unlink
Status in linux package in Ubuntu:
Fix Committed
Status in linux source package in Disco:
Fix Committed
Status in linux source package in Eoan:
Fix Committed
Bug description:
SRU Justification
Impact: All non-special files (For shiftfs this only includes fifos
and - for this case - unix sockets - since we don't allow character
and block devices to be created.) go through shiftfs_open() and have
their dentry pinned through this codepath preventing it from going
negative. But fifos don't use the shiftfs fops but rather use the
pipefifo_fops which means they do not go through shiftfs_open() and
thus don't have their dentry pinned that way. Thus, the lower dentries
for such files can go negative on unlink causing segfaults. The
following C program can be used to reproduce the crash:
#include
#include
#include
#include
#include
#include
#include
int main(int argc, char *argv[])
{
struct stat stat;
unlink("./bbb");
int ret = mknod("./bbb", S_IFIFO|0666, 0);
if (ret < 0)
exit(1);
int fd = open("./bbb", O_RDWR);
if (fd < 0)
exit(2);
if (unlink("./bbb"))
exit(4);
fstat(fd, );
return 0;
}
Fix: Similar to ecryptfs we need to dget() the lower dentry before
calling vfs_unlink() on it and dput() it afterwards.
Regression Potential: Limited to shiftfs.
Test Case: Compiled a kernel with the fix and used the reproducer
above to verify that the kernel cannot be crashed anymore.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1860041/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1865359] Re: sysfs: incorrect network device permissions on network namespace change
That's an old version, sorry. It's already in Dave's tree. The merge commit is here: https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/commit/?id=ebb4a4bf76f164457184a3f43ebc1552416bc823 -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1865359 Title: sysfs: incorrect network device permissions on network namespace change Status in linux package in Ubuntu: Confirmed Status in linux source package in Focal: Confirmed Bug description: SRU Justification Impact: patchsets.) We have been struggling with a bug surrounding the ownership of network device sysfs files when moving network devices between network namespaces owned by different user namespaces reported by multiple users. Currently, when moving network devices between network namespaces the ownership of the corresponding sysfs entries is not changed. This leads to problems when tools try to operate on the corresponding sysfs files. I also causes a bug when creating a network device in a network namespaces owned by a user namespace and moving that network device back to the host network namespaces. Because when a network device is created in a network namespaces it will be owned by the root user of the user namespace and all its associated sysfs files will also be owned by the root user of the corresponding user namespace. If such a network device has to be moved back to the host network namespace the permissions will still be set to the root user of the owning user namespaces of the originating network namespace. This means unprivileged users can e.g. re-trigger uevents for such incorrectly owned devices on the host or in other network namespaces. They can also modify the settings of the device itself through sysfs when they wouldn't be able to do the same through netlink. Both of these things are unwanted. For example, quite a few workloads will create network devices in the host network namespace. Other tools will then proceed to move such devices between network namespaces owner by other user namespaces. While the ownership of the device itself is updated in net/core/net-sysfs.c:dev_change_net_namespace() the corresponding sysfs entry for the device is not. Below you'll find that moving a network device (here a veth device) from a network namespace into another network namespaces owned by a different user namespace with a different id mapping. As you can see the permissions are wrong even though it is owned by the userns root user after it has been moved and can be interacted with through netlink: drwxr-xr-x 5 nobody nobody0 Jan 25 18:08 . drwxr-xr-x 9 nobody nobody0 Jan 25 18:08 .. -r--r--r-- 1 nobody nobody 4096 Jan 25 18:09 addr_assign_type -r--r--r-- 1 nobody nobody 4096 Jan 25 18:09 addr_len -r--r--r-- 1 nobody nobody 4096 Jan 25 18:09 address -r--r--r-- 1 nobody nobody 4096 Jan 25 18:09 broadcast -rw-r--r-- 1 nobody nobody 4096 Jan 25 18:09 carrier -r--r--r-- 1 nobody nobody 4096 Jan 25 18:09 carrier_changes -r--r--r-- 1 nobody nobody 4096 Jan 25 18:09 carrier_down_count -r--r--r-- 1 nobody nobody 4096 Jan 25 18:09 carrier_up_count -r--r--r-- 1 nobody nobody 4096 Jan 25 18:09 dev_id -r--r--r-- 1 nobody nobody 4096 Jan 25 18:09 dev_port -r--r--r-- 1 nobody nobody 4096 Jan 25 18:09 dormant -r--r--r-- 1 nobody nobody 4096 Jan 25 18:09 duplex -rw-r--r-- 1 nobody nobody 4096 Jan 25 18:09 flags -rw-r--r-- 1 nobody nobody 4096 Jan 25 18:09 gro_flush_timeout -rw-r--r-- 1 nobody nobody 4096 Jan 25 18:09 ifalias -r--r--r-- 1 nobody nobody 4096 Jan 25 18:09 ifindex -r--r--r-- 1 nobody nobody 4096 Jan 25 18:09 iflink -r--r--r-- 1 nobody nobody 4096 Jan 25 18:09 link_mode -rw-r--r-- 1 nobody nobody 4096 Jan 25 18:09 mtu -r--r--r-- 1 nobody nobody 4096 Jan 25 18:09 name_assign_type -rw-r--r-- 1 nobody nobody 4096 Jan 25 18:09 netdev_group -r--r--r-- 1 nobody nobody 4096 Jan 25 18:09 operstate -r--r--r-- 1 nobody nobody 4096 Jan 25 18:09 phys_port_id -r--r--r-- 1 nobody nobody 4096 Jan 25 18:09 phys_port_name -r--r--r-- 1 nobody nobody 4096 Jan 25 18:09 phys_switch_id drwxr-xr-x 2 nobody nobody0 Jan 25 18:09 power -rw-r--r-- 1 nobody nobody 4096 Jan 25 18:09 proto_down drwxr-xr-x 4 nobody nobody0 Jan 25 18:09 queues -r--r--r-- 1 nobody nobody 4096 Jan 25 18:09 speed drwxr-xr-x 2 nobody nobody0 Jan 25 18:09 statistics lrwxrwxrwx 1 nobody nobody0 Jan 25 18:08 subsystem -> ../../../../class/net -rw-r--r-- 1 nobody nobody 4096 Jan 25 18:09 tx_queue_len -r--r--r-- 1 nobody nobody 4096 Jan 25 18:09 type -rw-r--r-- 1 nobody nobody 4096 Jan 25 18:08 uevent Constrast this with creating a device of the same type in the network namespace directly. In this case the device's sysfs permissions will be correctly updated. (Please also note, that in a lot of
[Kernel-packages] [Bug 1865359] Re: sysfs: incorrect network device permissions on network namespace change
The patch series has been acked upstream and is sitting in Dave Miller's tree. We should backport it to 5.4! -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1865359 Title: sysfs: incorrect network device permissions on network namespace change Status in linux package in Ubuntu: Confirmed Bug description: SRU Justification Impact: patchsets.) We have been struggling with a bug surrounding the ownership of network device sysfs files when moving network devices between network namespaces owned by different user namespaces reported by multiple users. Currently, when moving network devices between network namespaces the ownership of the corresponding sysfs entries is not changed. This leads to problems when tools try to operate on the corresponding sysfs files. I also causes a bug when creating a network device in a network namespaces owned by a user namespace and moving that network device back to the host network namespaces. Because when a network device is created in a network namespaces it will be owned by the root user of the user namespace and all its associated sysfs files will also be owned by the root user of the corresponding user namespace. If such a network device has to be moved back to the host network namespace the permissions will still be set to the root user of the owning user namespaces of the originating network namespace. This means unprivileged users can e.g. re-trigger uevents for such incorrectly owned devices on the host or in other network namespaces. They can also modify the settings of the device itself through sysfs when they wouldn't be able to do the same through netlink. Both of these things are unwanted. For example, quite a few workloads will create network devices in the host network namespace. Other tools will then proceed to move such devices between network namespaces owner by other user namespaces. While the ownership of the device itself is updated in net/core/net-sysfs.c:dev_change_net_namespace() the corresponding sysfs entry for the device is not. Below you'll find that moving a network device (here a veth device) from a network namespace into another network namespaces owned by a different user namespace with a different id mapping. As you can see the permissions are wrong even though it is owned by the userns root user after it has been moved and can be interacted with through netlink: drwxr-xr-x 5 nobody nobody0 Jan 25 18:08 . drwxr-xr-x 9 nobody nobody0 Jan 25 18:08 .. -r--r--r-- 1 nobody nobody 4096 Jan 25 18:09 addr_assign_type -r--r--r-- 1 nobody nobody 4096 Jan 25 18:09 addr_len -r--r--r-- 1 nobody nobody 4096 Jan 25 18:09 address -r--r--r-- 1 nobody nobody 4096 Jan 25 18:09 broadcast -rw-r--r-- 1 nobody nobody 4096 Jan 25 18:09 carrier -r--r--r-- 1 nobody nobody 4096 Jan 25 18:09 carrier_changes -r--r--r-- 1 nobody nobody 4096 Jan 25 18:09 carrier_down_count -r--r--r-- 1 nobody nobody 4096 Jan 25 18:09 carrier_up_count -r--r--r-- 1 nobody nobody 4096 Jan 25 18:09 dev_id -r--r--r-- 1 nobody nobody 4096 Jan 25 18:09 dev_port -r--r--r-- 1 nobody nobody 4096 Jan 25 18:09 dormant -r--r--r-- 1 nobody nobody 4096 Jan 25 18:09 duplex -rw-r--r-- 1 nobody nobody 4096 Jan 25 18:09 flags -rw-r--r-- 1 nobody nobody 4096 Jan 25 18:09 gro_flush_timeout -rw-r--r-- 1 nobody nobody 4096 Jan 25 18:09 ifalias -r--r--r-- 1 nobody nobody 4096 Jan 25 18:09 ifindex -r--r--r-- 1 nobody nobody 4096 Jan 25 18:09 iflink -r--r--r-- 1 nobody nobody 4096 Jan 25 18:09 link_mode -rw-r--r-- 1 nobody nobody 4096 Jan 25 18:09 mtu -r--r--r-- 1 nobody nobody 4096 Jan 25 18:09 name_assign_type -rw-r--r-- 1 nobody nobody 4096 Jan 25 18:09 netdev_group -r--r--r-- 1 nobody nobody 4096 Jan 25 18:09 operstate -r--r--r-- 1 nobody nobody 4096 Jan 25 18:09 phys_port_id -r--r--r-- 1 nobody nobody 4096 Jan 25 18:09 phys_port_name -r--r--r-- 1 nobody nobody 4096 Jan 25 18:09 phys_switch_id drwxr-xr-x 2 nobody nobody0 Jan 25 18:09 power -rw-r--r-- 1 nobody nobody 4096 Jan 25 18:09 proto_down drwxr-xr-x 4 nobody nobody0 Jan 25 18:09 queues -r--r--r-- 1 nobody nobody 4096 Jan 25 18:09 speed drwxr-xr-x 2 nobody nobody0 Jan 25 18:09 statistics lrwxrwxrwx 1 nobody nobody0 Jan 25 18:08 subsystem -> ../../../../class/net -rw-r--r-- 1 nobody nobody 4096 Jan 25 18:09 tx_queue_len -r--r--r-- 1 nobody nobody 4096 Jan 25 18:09 type -rw-r--r-- 1 nobody nobody 4096 Jan 25 18:08 uevent Constrast this with creating a device of the same type in the network namespace directly. In this case the device's sysfs permissions will be correctly updated. (Please also note, that in a lot of workloads this strategy of creating the network device directly in the network device to workaround this issue can not be used. Either because the
[Kernel-packages] [Bug 1865359] [NEW] sysfs: incorrect network device permissions on network namespace change
Public bug reported: SRU Justification Impact: patchsets.) We have been struggling with a bug surrounding the ownership of network device sysfs files when moving network devices between network namespaces owned by different user namespaces reported by multiple users. Currently, when moving network devices between network namespaces the ownership of the corresponding sysfs entries is not changed. This leads to problems when tools try to operate on the corresponding sysfs files. I also causes a bug when creating a network device in a network namespaces owned by a user namespace and moving that network device back to the host network namespaces. Because when a network device is created in a network namespaces it will be owned by the root user of the user namespace and all its associated sysfs files will also be owned by the root user of the corresponding user namespace. If such a network device has to be moved back to the host network namespace the permissions will still be set to the root user of the owning user namespaces of the originating network namespace. This means unprivileged users can e.g. re-trigger uevents for such incorrectly owned devices on the host or in other network namespaces. They can also modify the settings of the device itself through sysfs when they wouldn't be able to do the same through netlink. Both of these things are unwanted. For example, quite a few workloads will create network devices in the host network namespace. Other tools will then proceed to move such devices between network namespaces owner by other user namespaces. While the ownership of the device itself is updated in net/core/net-sysfs.c:dev_change_net_namespace() the corresponding sysfs entry for the device is not. Below you'll find that moving a network device (here a veth device) from a network namespace into another network namespaces owned by a different user namespace with a different id mapping. As you can see the permissions are wrong even though it is owned by the userns root user after it has been moved and can be interacted with through netlink: drwxr-xr-x 5 nobody nobody0 Jan 25 18:08 . drwxr-xr-x 9 nobody nobody0 Jan 25 18:08 .. -r--r--r-- 1 nobody nobody 4096 Jan 25 18:09 addr_assign_type -r--r--r-- 1 nobody nobody 4096 Jan 25 18:09 addr_len -r--r--r-- 1 nobody nobody 4096 Jan 25 18:09 address -r--r--r-- 1 nobody nobody 4096 Jan 25 18:09 broadcast -rw-r--r-- 1 nobody nobody 4096 Jan 25 18:09 carrier -r--r--r-- 1 nobody nobody 4096 Jan 25 18:09 carrier_changes -r--r--r-- 1 nobody nobody 4096 Jan 25 18:09 carrier_down_count -r--r--r-- 1 nobody nobody 4096 Jan 25 18:09 carrier_up_count -r--r--r-- 1 nobody nobody 4096 Jan 25 18:09 dev_id -r--r--r-- 1 nobody nobody 4096 Jan 25 18:09 dev_port -r--r--r-- 1 nobody nobody 4096 Jan 25 18:09 dormant -r--r--r-- 1 nobody nobody 4096 Jan 25 18:09 duplex -rw-r--r-- 1 nobody nobody 4096 Jan 25 18:09 flags -rw-r--r-- 1 nobody nobody 4096 Jan 25 18:09 gro_flush_timeout -rw-r--r-- 1 nobody nobody 4096 Jan 25 18:09 ifalias -r--r--r-- 1 nobody nobody 4096 Jan 25 18:09 ifindex -r--r--r-- 1 nobody nobody 4096 Jan 25 18:09 iflink -r--r--r-- 1 nobody nobody 4096 Jan 25 18:09 link_mode -rw-r--r-- 1 nobody nobody 4096 Jan 25 18:09 mtu -r--r--r-- 1 nobody nobody 4096 Jan 25 18:09 name_assign_type -rw-r--r-- 1 nobody nobody 4096 Jan 25 18:09 netdev_group -r--r--r-- 1 nobody nobody 4096 Jan 25 18:09 operstate -r--r--r-- 1 nobody nobody 4096 Jan 25 18:09 phys_port_id -r--r--r-- 1 nobody nobody 4096 Jan 25 18:09 phys_port_name -r--r--r-- 1 nobody nobody 4096 Jan 25 18:09 phys_switch_id drwxr-xr-x 2 nobody nobody0 Jan 25 18:09 power -rw-r--r-- 1 nobody nobody 4096 Jan 25 18:09 proto_down drwxr-xr-x 4 nobody nobody0 Jan 25 18:09 queues -r--r--r-- 1 nobody nobody 4096 Jan 25 18:09 speed drwxr-xr-x 2 nobody nobody0 Jan 25 18:09 statistics lrwxrwxrwx 1 nobody nobody0 Jan 25 18:08 subsystem -> ../../../../class/net -rw-r--r-- 1 nobody nobody 4096 Jan 25 18:09 tx_queue_len -r--r--r-- 1 nobody nobody 4096 Jan 25 18:09 type -rw-r--r-- 1 nobody nobody 4096 Jan 25 18:08 uevent Constrast this with creating a device of the same type in the network namespace directly. In this case the device's sysfs permissions will be correctly updated. (Please also note, that in a lot of workloads this strategy of creating the network device directly in the network device to workaround this issue can not be used. Either because the network device is dedicated after it has been created or because it used by a process that is heavily sandboxed and couldn't create network devices itself.): drwxr-xr-x 5 root root 0 Jan 25 18:12 . drwxr-xr-x 9 nobody nobody0 Jan 25 18:08 .. -r--r--r-- 1 root root 4096 Jan 25 18:12 addr_assign_type -r--r--r-- 1 root root 4096 Jan 25 18:12 addr_len -r--r--r-- 1 root root 4096 Jan 25 18:12 address -r--r--r-- 1 root root 4096 Jan 25 18:12 broadcast -rw-r--r-- 1 root root 4096 Jan 25 18:12 carrier -r--r--r-- 1 root root
[Kernel-packages] [Bug 1860041] [NEW] shiftfs: prevent lower dentries from going negative during unlink
Public bug reported:
SRU Justification
Impact: All non-special files (For shiftfs this only includes fifos and
- for this case - unix sockets - since we don't allow character and
block devices to be created.) go through shiftfs_open() and have their
dentry pinned through this codepath preventing it from going negative.
But fifos don't use the shiftfs fops but rather use the pipefifo_fops
which means they do not go through shiftfs_open() and thus don't have
their dentry pinned that way. Thus, the lower dentries for such files
can go negative on unlink causing segfaults. The following C program can
be used to reproduce the crash:
#include
#include
#include
#include
#include
#include
#include
int main(int argc, char *argv[])
{
struct stat stat;
unlink("./bbb");
int ret = mknod("./bbb", S_IFIFO|0666, 0);
if (ret < 0)
exit(1);
int fd = open("./bbb", O_RDWR);
if (fd < 0)
exit(2);
if (unlink("./bbb"))
exit(4);
fstat(fd, );
return 0;
}
Fix: Similar to ecryptfs we need to dget() the lower dentry before
calling vfs_unlink() on it and dput() it afterwards.
Regression Potential: Limited to shiftfs.
Test Case: Compiled a kernel with the fix and used the reproducer above
to verify that the kernel cannot be crashed anymore.
** Affects: linux (Ubuntu)
Importance: Undecided
Assignee: Christian Brauner (cbrauner)
Status: In Progress
** Changed in: linux (Ubuntu)
Status: New => Confirmed
** Changed in: linux (Ubuntu)
Status: Confirmed => In Progress
** Changed in: linux (Ubuntu)
Assignee: (unassigned) => Christian Brauner (cbrauner)
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1860041
Title:
shiftfs: prevent lower dentries from going negative during unlink
Status in linux package in Ubuntu:
In Progress
Bug description:
SRU Justification
Impact: All non-special files (For shiftfs this only includes fifos
and - for this case - unix sockets - since we don't allow character
and block devices to be created.) go through shiftfs_open() and have
their dentry pinned through this codepath preventing it from going
negative. But fifos don't use the shiftfs fops but rather use the
pipefifo_fops which means they do not go through shiftfs_open() and
thus don't have their dentry pinned that way. Thus, the lower dentries
for such files can go negative on unlink causing segfaults. The
following C program can be used to reproduce the crash:
#include
#include
#include
#include
#include
#include
#include
int main(int argc, char *argv[])
{
struct stat stat;
unlink("./bbb");
int ret = mknod("./bbb", S_IFIFO|0666, 0);
if (ret < 0)
exit(1);
int fd = open("./bbb", O_RDWR);
if (fd < 0)
exit(2);
if (unlink("./bbb"))
exit(4);
fstat(fd, );
return 0;
}
Fix: Similar to ecryptfs we need to dget() the lower dentry before
calling vfs_unlink() on it and dput() it afterwards.
Regression Potential: Limited to shiftfs.
Test Case: Compiled a kernel with the fix and used the reproducer
above to verify that the kernel cannot be crashed anymore.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1860041/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
Re: [Kernel-packages] [Bug 1857257] Re: linux-image-5.0.0-35-generic breaks checkpointing of container
On Tue, Jan 07, 2020 at 07:07:36PM -, Andrew Vagin wrote: > The root cause of this fail is a wrong mount ID which is reported for > file mappings: If you have cycles to come up with a patch to fix this that would be appreciated. Otherwise this will end up lower in my priority queue since my backlog is quite full atm. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1857257 Title: linux-image-5.0.0-35-generic breaks checkpointing of container Status in linux package in Ubuntu: Confirmed Bug description: Trying to checkpoint a container (docker/podman) on 18.04 fails starting with linux-image-5.0.0-35-generic. We (CRIU upstream) see this in Travis starting a few weeks ago. Manually testing it locally shows that linux-image-5.0.0-32-generic still works and linux- image-5.0.0-35-generic does not longer work. It seems to be overlayfs related, at least that is what we believe. The CRIU error message we see is: (00.170944) Error (criu/files-reg.c:1277): Can't lookup mount=410 for fd=-3 path=/bin/busybox (00.170987) Error (criu/cr-dump.c:1246): Collect mappings (pid: 1637) failed with -1 We have not seen this only in Travis, but also multiple CRIU users reported that bug already. Currently we have to tell them to downgrade the kernel. I also able to reproduce it with linux-image-5.3.0-24-generic. Staying on the 4.18.0 kernel series does not show this error. 4.18.0-25-generic works without problems. See also https://github.com/checkpoint-restore/criu/issues/860 One of the possible explanations from our side include: "Looks like we have the same as for st_dev now with mnt_id, that is bad, because we can't find on which mount to open the file if kernel hides these information from us." Running on the upstream 5.5.0-rc1 kernel does not show this error. --- ProblemType: Bug AlsaDevices: total 0 crw-rw 1 root audio 116, 1 Jan 7 18:52 seq crw-rw 1 root audio 116, 33 Jan 7 18:52 timer AplayDevices: Error: [Errno 2] No such file or directory: 'aplay': 'aplay' ApportVersion: 2.20.11-0ubuntu8.2 Architecture: amd64 ArecordDevices: Error: [Errno 2] No such file or directory: 'arecord': 'arecord' AudioDevicesInUse: Error: command ['fuser', '-v', '/dev/snd/seq', '/dev/snd/timer'] failed with exit code 1: CRDA: N/A DistroRelease: Ubuntu 19.10 IwConfig: Error: [Errno 2] No such file or directory: 'iwconfig': 'iwconfig' Lsusb: Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub MachineType: DigitalOcean Droplet Package: linux (not installed) PciMultimedia: ProcFB: ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.3.0-26-generic root=PARTUUID=5b57f3f9-086a-4a7d-ae78-efdee8842586 ro console=tty1 console=ttyS0 ProcVersionSignature: Ubuntu 5.3.0-26.28-generic 5.3.13 RelatedPackageVersions: linux-restricted-modules-5.3.0-26-generic N/A linux-backports-modules-5.3.0-26-generic N/A linux-firmwareN/A RfKill: Error: [Errno 2] No such file or directory: 'rfkill': 'rfkill' Tags: eoan uec-images Uname: Linux 5.3.0-26-generic x86_64 UpgradeStatus: No upgrade log present (probably fresh install) UserGroups: _MarkForUpload: True dmi.bios.date: 12/12/2017 dmi.bios.vendor: DigitalOcean dmi.bios.version: 20171212 dmi.chassis.type: 1 dmi.chassis.vendor: Bochs dmi.modalias: dmi:bvnDigitalOcean:bvr20171212:bd12/12/2017:svnDigitalOcean:pnDroplet:pvr20171212:cvnBochs:ct1:cvr: dmi.product.family: DigitalOcean_Droplet dmi.product.name: Droplet dmi.product.version: 20171212 dmi.sys.vendor: DigitalOcean To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1857257/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1849482] Re: shiftfs: fix fallocate()
** Tags removed: verification-needed-disco verification-needed-eoan ** Tags added: verification-done-disco verification-done-eoan -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1849482 Title: shiftfs: fix fallocate() Status in linux package in Ubuntu: Fix Committed Status in linux source package in Disco: Fix Committed Status in linux source package in Eoan: Fix Committed Bug description: SRU Justification Impact: Currently shiftfs limits the maximum size for fallocate() needlessly causing calls such as fallocate --length 2GB ./file to fail. This limitation is arbitrary since it's not caused by the underlay but rather by shiftfs itself capping the s_maxbytes. This causes bugs such as the one reported in https://github.com/lxc/lxd/issues/6333. Fix: Currectly set up s_maxbytes when creating the shiftfs superblock. Regression Potential: Limited to shiftfs. Test Case: Try fallocate --length 3GB ./file on top of a filesystem with fallocate support on a fixed kernel and see that the call succeeds and the file is of the expected size. Target Kernels: All LTS kernels with shiftfs support. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1849482/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1849483] Re: shiftfs: prevent exceeding project quotas
** Tags removed: verification-needed-disco verification-needed-eoan ** Tags added: verification-done-disco verification-done-eoan -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1849483 Title: shiftfs: prevent exceeding project quotas Status in linux package in Ubuntu: Fix Committed Status in linux source package in Disco: Fix Committed Status in linux source package in Eoan: Fix Committed Bug description: SRU Justification Impact: Currently shiftfs allows to exceed project quota and reserved space on e.g. ext2. See https://github.com/lxc/lxd/issues/6333 for a report, specifically https://github.com/lxc/lxd/issues/6333#issuecomment-545154838. This is caused by overriding the credentials with the superblock creator's credentials whenever we perform operations such as fallocate() or writes while retaining CAP_SYS_RESOURCE. Fix: Drop CAP_SYS_RESOURCE at superblock creation time from the effective capability set. Regression Potential: Limited to shiftfs. Dropping CAP_SYS_RESOURCE from the effective capability set should be fine and actually give us more security. Test Case: Try to exceed project quotas on a kernel and filesystem that supports them and see that it fails with the mentioned fix applied. Target Kernels: All LTS kernels with shiftfs support. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1849483/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1849281] Re: seccomp: fix SECCOMP_USER_NOTIF_FLAG_CONTINUE test
** Tags removed: verification-needed-disco verification-needed-eoan ** Tags added: verification-done-disco verification-done-eoan -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1849281 Title: seccomp: fix SECCOMP_USER_NOTIF_FLAG_CONTINUE test Status in ubuntu-kernel-tests: New Status in linux package in Ubuntu: Fix Committed Status in linux source package in Disco: Fix Committed Status in linux source package in Eoan: Fix Committed Bug description: SRU Justification Impact: We recently backported SECCOMP_USER_NOTIF_FLAG_CONTINUE in https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1847744. On a kernel that supports SECCOMP_FILTER_FLAG_NEW_LISTENER but not SECCOMP_USER_NOTIF_FLAG_CONTINUE the selftests currently fail to compile. The reason is that the ifndef for SECCOMP_USER_NOTIF_FLAG_CONTINUE is placed under the ifndef for SECCOMP_FILTER_FLAG_NEW_LISTENER. Fix: The ifndef for SECCOMP_USER_NOTIF_FLAG_CONTINUE was placed under the ifndef for the SECCOMP_FILTER_FLAG_NEW_LISTENER feature. This will not work on systems that do support SECCOMP_FILTER_FLAG_NEW_LISTENER but do not support SECCOMP_USER_NOTIF_FLAG_CONTINUE. So move the latter ifndef out of the former ifndef's scope. Regression Potential: Limited to seccomp selftests. Test Case: Compile the selftests on a kernel that supports SECCOMP_FILTER_FLAG_NEW_LISTENER but does not support SECCOMP_USER_NOTIF_FLAG_CONTINUE and see that compilations succeeds. Target Kernels: All current LTS kernels with access to a 5.0 kernel. Patches: https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git/commit/?h=for-next/seccomp=2aa8d8d04ca29c3269154e1d48855e498be8882f To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-kernel-tests/+bug/1849281/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1846265] Re: shiftfs: rework how shiftfs opens files
** Tags removed: verification-needed-eoan ** Tags added: verification-done-eoan -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1846265 Title: shiftfs: rework how shiftfs opens files Status in linux package in Ubuntu: Fix Committed Status in linux source package in Eoan: Fix Committed Bug description: SRU Justification Impact: Currently, shiftfs maintains a kmem cache for struct shiftfs_file_info which stashes away a struct path and the struct file for the underlay. The path however is never used anywhere so the struct shiftfs_file_info and therefore the whole kmem cache can go away. This removes code and makes the whole logic simpler to understand and reason about. Fix: Remove the kmem cache for struct shiftfs_file_info and struct shiftfs_file_info itself and move to the same model as overlayfs and just stash away the struct file for the underlay in file->private_data of the shiftfs struct file Regression Potential: Limited to shiftfs. The basic logic is unchanged. It is just simplified so regression potential should be fairly low. Test Case: Tested with LXD on a kernel with the patch applied and running various standard workloads without any observable regressions. Target Kernels: All LTS kernels with support for shiftfs. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1846265/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1847744] Re: seccomp: add SECCOMP_USER_NOTIF_FLAG_CONTINUE
** Tags removed: verification-needed-disco verification-needed-eoan
** Tags added: verification-done-disco verification-done-eoan
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1847744
Title:
seccomp: add SECCOMP_USER_NOTIF_FLAG_CONTINUE
Status in linux package in Ubuntu:
Fix Committed
Status in linux source package in Disco:
Fix Committed
Status in linux source package in Eoan:
Fix Committed
Bug description:
SRU Justification
Impact: Recently we landed seccomp support for SECCOMP_RET_USER_NOTIF
(cf. [4]) which enables a process (watchee) to retrieve an fd for its
seccomp filter. This fd can then be handed to another (usually more
privileged) process (watcher). The watcher will then be able to
receive seccomp messages about the syscalls having been performed by
the watchee.
This feature is heavily used in some userspace workloads. For example,
it is currently used to intercept mknod() syscalls in user namespaces
aka in containers. The mknod() syscall can be easily filtered based on
dev_t. This allows us to only intercept a very specific subset of
mknod() syscalls. Furthermore, mknod() is not possible in user
namespaces toto coelo and so intercepting and denying syscalls that
are not in the whitelist on accident is not a big deal. The watchee
won't notice a difference.
In contrast to mknod(), a lot of other syscall we intercept (e.g. setxattr())
cannot be easily filtered like mknod() because they have pointer arguments.
Additionally, some of them might actually succeed in user namespaces (e.g.
setxattr() for all "user.*" xattrs). Since we currently cannot tell seccomp to
continue from a user notifier we are stuck with performing all of the syscalls
in lieu of the container. This is a huge security liability since it is
extremely difficult to correctly assume all of the necessary privileges of the
calling task
such that the syscall can be successfully emulated without escaping other
additional security restrictions (think missing CAP_MKNOD for mknod(), or
MS_NODEV on a filesystem etc.). This can be solved by telling seccomp to resume
the syscall.
Fix: Allow the seccomp notifier to continue a syscall. A positive
discussion about this feature was triggered by a post to the ksummit-
discuss mailing list (cf. [3]) and took place during KSummit (cf. [1])
and again at the containers/checkpoint-restore micro-conference at
Linux Plumbers.
Regression Potential: Limited to seccomp. The patchset also comes with
proper selftests in addition to the large set of seccomp selftests
that are already there. This further reduces regression potential.
Test Case:
Compile a kernel with the patch applied and run the selftests or trap a
syscall via the notifier fd and set the newly introduced flag. The syscall
should then have continued.
Target Kernels: All current LTS kernels.
Patches:
https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git/commit/?h=for-next/seccomp=fb3c5386b382d4097476ce9647260fc89b34afdb
https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git/commit/?h=for-next/seccomp=0eebfed2954f152259cae0ad57b91d3ea92968e8
/* References */
[1]: https://linuxplumbersconf.org/event/4/contributions/560
[2]: https://linuxplumbersconf.org/event/4/contributions/477
[3]: https://lore.kernel.org/r/20190719093538.dhyopljyr5ns3...@brauner.io
[4]: commit 6a21cc50f0c7 ("seccomp: add a return code to trap to userspace")
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1847744/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1846272] Re: overlayfs: allow with shiftfs as underlay
** Tags removed: verification-needed-eoan ** Tags added: verification-done-eoan -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1846272 Title: overlayfs: allow with shiftfs as underlay Status in linux package in Ubuntu: Fix Committed Status in linux source package in Disco: Fix Committed Status in linux source package in Eoan: Fix Committed Bug description: SRU Justification Impact: Currently it is not possible to use overlayfs on top of shiftfs. This means Docker inside of LXD cannot make user of the overlay2 graph driver which is blocking users such as Travis from making use of it efficiently. Regression Potential: Limited to shiftfs and overlayfs on top of shiftfs. Overlayfs does prevent "remote" filesystems such as ceph, nfs, etc. from being used as the underlay. With this patch shiftfs however can be used as an underlay and we special case it as a suitable filesystem to be used under overlayfs. I verified that the patch does not lead to regression on overlayfs workloads that do not make use of shiftfs as underlay. Additionally, I tested Docker with the overlay2 graphdriver on top of shiftfs. This also has not lead to any regressions. Test case: Building a kernel with the patch: sudo snap install lxd sudo lxd init sudo lxc launch images:ubuntu/bionic b1 sudo lxc config set b1 security.nesting true sudo lxc restart --force b1 sudo lxc shell b1 sudo apt-get install \ apt-transport-https \ ca-certificates \ curl \ gnupg-agent \ software-properties-common curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add - curl -fsSL get.docker.com | CHANNEL=test sh sudo add-apt-repository \ "deb [arch=amd64] https://download.docker.com/linux/ubuntu \ $(lsb_release -cs) \ stable" sudo apt-get update sudo apt-get install docker-ce docker-ce-cli containerd.io sudo systemctl stop docker cat
[Kernel-packages] [Bug 1849483] [NEW] shiftfs: prevent exceeding project quotas
Public bug reported: SRU Justification Impact: Currently shiftfs allows to exceed project quota and reserved space on e.g. ext2. See https://github.com/lxc/lxd/issues/6333 for a report, specifically https://github.com/lxc/lxd/issues/6333#issuecomment-545154838. This is caused by overriding the credentials with the superblock creator's credentials whenever we perform operations such as fallocate() or writes while retaining CAP_SYS_RESOURCE. Fix: Drop CAP_SYS_RESOURCE at superblock creation time from the effective capability set. Regression Potential: Limited to shiftfs. Dropping CAP_SYS_RESOURCE from the effective capability set should be fine and actually give us more security. Test Case: Try to exceed project quotas on a kernel and filesystem that supports them and see that it fails with the mentioned fix applied. Target Kernels: All LTS kernels with shiftfs support. ** Affects: linux (Ubuntu) Importance: Undecided Assignee: Christian Brauner (cbrauner) Status: In Progress ** Changed in: linux (Ubuntu) Assignee: (unassigned) => Christian Brauner (cbrauner) ** Changed in: linux (Ubuntu) Status: New => In Progress -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1849483 Title: shiftfs: prevent exceeding project quotas Status in linux package in Ubuntu: In Progress Bug description: SRU Justification Impact: Currently shiftfs allows to exceed project quota and reserved space on e.g. ext2. See https://github.com/lxc/lxd/issues/6333 for a report, specifically https://github.com/lxc/lxd/issues/6333#issuecomment-545154838. This is caused by overriding the credentials with the superblock creator's credentials whenever we perform operations such as fallocate() or writes while retaining CAP_SYS_RESOURCE. Fix: Drop CAP_SYS_RESOURCE at superblock creation time from the effective capability set. Regression Potential: Limited to shiftfs. Dropping CAP_SYS_RESOURCE from the effective capability set should be fine and actually give us more security. Test Case: Try to exceed project quotas on a kernel and filesystem that supports them and see that it fails with the mentioned fix applied. Target Kernels: All LTS kernels with shiftfs support. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1849483/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1849482] [NEW] shiftfs: fix fallocate()
Public bug reported: SRU Justification Impact: Currently shiftfs limits the maximum size for fallocate() needlessly causing calls such as fallocate --length 2GB ./file to fail. This limitation is arbitrary since it's not caused by the underlay but rather by shiftfs itself capping the s_maxbytes. This causes bugs such as the one reported in https://github.com/lxc/lxd/issues/6333. Fix: Currectly set up s_maxbytes when creating the shiftfs superblock. Regression Potential: Limited to shiftfs. Test Case: Try fallocate --length 3GB ./file on top of a filesystem with fallocate support on a fixed kernel and see that the call succeeds and the file is of the expected size. Target Kernels: All LTS kernels with shiftfs support. ** Affects: linux (Ubuntu) Importance: Undecided Assignee: Christian Brauner (cbrauner) Status: In Progress ** Changed in: linux (Ubuntu) Assignee: (unassigned) => Christian Brauner (cbrauner) ** Changed in: linux (Ubuntu) Status: New => In Progress -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1849482 Title: shiftfs: fix fallocate() Status in linux package in Ubuntu: In Progress Bug description: SRU Justification Impact: Currently shiftfs limits the maximum size for fallocate() needlessly causing calls such as fallocate --length 2GB ./file to fail. This limitation is arbitrary since it's not caused by the underlay but rather by shiftfs itself capping the s_maxbytes. This causes bugs such as the one reported in https://github.com/lxc/lxd/issues/6333. Fix: Currectly set up s_maxbytes when creating the shiftfs superblock. Regression Potential: Limited to shiftfs. Test Case: Try fallocate --length 3GB ./file on top of a filesystem with fallocate support on a fixed kernel and see that the call succeeds and the file is of the expected size. Target Kernels: All LTS kernels with shiftfs support. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1849482/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1846272] Re: overlayfs: allow with shiftfs as underlay
** Tags removed: verification-needed-disco ** Tags added: verification-done-disco -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1846272 Title: overlayfs: allow with shiftfs as underlay Status in linux package in Ubuntu: Fix Committed Status in linux source package in Disco: Fix Committed Status in linux source package in Eoan: Fix Committed Bug description: SRU Justification Impact: Currently it is not possible to use overlayfs on top of shiftfs. This means Docker inside of LXD cannot make user of the overlay2 graph driver which is blocking users such as Travis from making use of it efficiently. Regression Potential: Limited to shiftfs and overlayfs on top of shiftfs. Overlayfs does prevent "remote" filesystems such as ceph, nfs, etc. from being used as the underlay. With this patch shiftfs however can be used as an underlay and we special case it as a suitable filesystem to be used under overlayfs. I verified that the patch does not lead to regression on overlayfs workloads that do not make use of shiftfs as underlay. Additionally, I tested Docker with the overlay2 graphdriver on top of shiftfs. This also has not lead to any regressions. Test case: Building a kernel with the patch: sudo snap install lxd sudo lxd init sudo lxc launch images:ubuntu/bionic b1 sudo lxc config set b1 security.nesting true sudo lxc restart --force b1 sudo lxc shell b1 sudo apt-get install \ apt-transport-https \ ca-certificates \ curl \ gnupg-agent \ software-properties-common curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add - curl -fsSL get.docker.com | CHANNEL=test sh sudo add-apt-repository \ "deb [arch=amd64] https://download.docker.com/linux/ubuntu \ $(lsb_release -cs) \ stable" sudo apt-get update sudo apt-get install docker-ce docker-ce-cli containerd.io sudo systemctl stop docker cat
[Kernel-packages] [Bug 1849281] [NEW] seccomp: fix SECCOMP_USER_NOTIF_FLAG_CONTINUE test
Public bug reported: SRU Justification Impact: We recently backported SECCOMP_USER_NOTIF_FLAG_CONTINUE in https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1847744. On a kernel that supports SECCOMP_FILTER_FLAG_NEW_LISTENER but not SECCOMP_USER_NOTIF_FLAG_CONTINUE the selftests currently fail to compile. The reason is that the ifndef for SECCOMP_USER_NOTIF_FLAG_CONTINUE is placed under the ifndef for SECCOMP_FILTER_FLAG_NEW_LISTENER. Fix: The ifndef for SECCOMP_USER_NOTIF_FLAG_CONTINUE was placed under the ifndef for the SECCOMP_FILTER_FLAG_NEW_LISTENER feature. This will not work on systems that do support SECCOMP_FILTER_FLAG_NEW_LISTENER but do not support SECCOMP_USER_NOTIF_FLAG_CONTINUE. So move the latter ifndef out of the former ifndef's scope. Regression Potential: Limited to seccomp selftests. Test Case: Compile the selftests on a kernel that supports SECCOMP_FILTER_FLAG_NEW_LISTENER but does not support SECCOMP_USER_NOTIF_FLAG_CONTINUE and see that compilations succeeds. Target Kernels: All current LTS kernels with access to a 5.0 kernel. Patches: https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git/commit/?h=for-next/seccomp=2aa8d8d04ca29c3269154e1d48855e498be8882f ** Affects: linux (Ubuntu) Importance: Undecided Assignee: Christian Brauner (cbrauner) Status: In Progress ** Changed in: linux (Ubuntu) Status: New => In Progress ** Changed in: linux (Ubuntu) Assignee: (unassigned) => Christian Brauner (cbrauner) -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1849281 Title: seccomp: fix SECCOMP_USER_NOTIF_FLAG_CONTINUE test Status in linux package in Ubuntu: In Progress Bug description: SRU Justification Impact: We recently backported SECCOMP_USER_NOTIF_FLAG_CONTINUE in https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1847744. On a kernel that supports SECCOMP_FILTER_FLAG_NEW_LISTENER but not SECCOMP_USER_NOTIF_FLAG_CONTINUE the selftests currently fail to compile. The reason is that the ifndef for SECCOMP_USER_NOTIF_FLAG_CONTINUE is placed under the ifndef for SECCOMP_FILTER_FLAG_NEW_LISTENER. Fix: The ifndef for SECCOMP_USER_NOTIF_FLAG_CONTINUE was placed under the ifndef for the SECCOMP_FILTER_FLAG_NEW_LISTENER feature. This will not work on systems that do support SECCOMP_FILTER_FLAG_NEW_LISTENER but do not support SECCOMP_USER_NOTIF_FLAG_CONTINUE. So move the latter ifndef out of the former ifndef's scope. Regression Potential: Limited to seccomp selftests. Test Case: Compile the selftests on a kernel that supports SECCOMP_FILTER_FLAG_NEW_LISTENER but does not support SECCOMP_USER_NOTIF_FLAG_CONTINUE and see that compilations succeeds. Target Kernels: All current LTS kernels with access to a 5.0 kernel. Patches: https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git/commit/?h=for-next/seccomp=2aa8d8d04ca29c3269154e1d48855e498be8882f To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1849281/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1847744] [NEW] seccomp: add SECCOMP_USER_NOTIF_FLAG_CONTINUE
Public bug reported:
SRU Justification
Impact: Recently we landed seccomp support for SECCOMP_RET_USER_NOTIF
(cf. [4]) which enables a process (watchee) to retrieve an fd for its
seccomp filter. This fd can then be handed to another (usually more
privileged) process (watcher). The watcher will then be able to receive
seccomp messages about the syscalls having been performed by the
watchee.
This feature is heavily used in some userspace workloads. For example,
it is currently used to intercept mknod() syscalls in user namespaces
aka in containers. The mknod() syscall can be easily filtered based on
dev_t. This allows us to only intercept a very specific subset of
mknod() syscalls. Furthermore, mknod() is not possible in user
namespaces toto coelo and so intercepting and denying syscalls that are
not in the whitelist on accident is not a big deal. The watchee won't
notice a difference.
In contrast to mknod(), a lot of other syscall we intercept (e.g. setxattr())
cannot be easily filtered like mknod() because they have pointer arguments.
Additionally, some of them might actually succeed in user namespaces (e.g.
setxattr() for all "user.*" xattrs). Since we currently cannot tell seccomp to
continue from a user notifier we are stuck with performing all of the syscalls
in lieu of the container. This is a huge security liability since it is
extremely difficult to correctly assume all of the necessary privileges of the
calling task
such that the syscall can be successfully emulated without escaping other
additional security restrictions (think missing CAP_MKNOD for mknod(), or
MS_NODEV on a filesystem etc.). This can be solved by telling seccomp to resume
the syscall.
Fix: Allow the seccomp notifier to continue a syscall. A positive
discussion about this feature was triggered by a post to the ksummit-
discuss mailing list (cf. [3]) and took place during KSummit (cf. [1])
and again at the containers/checkpoint-restore micro-conference at Linux
Plumbers.
Regression Potential: Limited to seccomp. The patchset also comes with
proper selftests in addition to the large set of seccomp selftests that
are already there. This further reduces regression potential.
Test Case:
Compile a kernel with the patch applied and run the selftests or trap a syscall
via the notifier fd and set the newly introduced flag. The syscall should then
have continued.
Target Kernels: All current LTS kernels.
Patches:
https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git/commit/?h=for-next/seccomp=fb3c5386b382d4097476ce9647260fc89b34afdb
https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git/commit/?h=for-next/seccomp=0eebfed2954f152259cae0ad57b91d3ea92968e8
/* References */
[1]: https://linuxplumbersconf.org/event/4/contributions/560
[2]: https://linuxplumbersconf.org/event/4/contributions/477
[3]: https://lore.kernel.org/r/20190719093538.dhyopljyr5ns3...@brauner.io
[4]: commit 6a21cc50f0c7 ("seccomp: add a return code to trap to userspace")
** Affects: linux (Ubuntu)
Importance: Undecided
Assignee: Christian Brauner (cbrauner)
Status: In Progress
** Changed in: linux (Ubuntu)
Assignee: (unassigned) => Christian Brauner (cbrauner)
** Changed in: linux (Ubuntu)
Status: New => In Progress
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1847744
Title:
seccomp: add SECCOMP_USER_NOTIF_FLAG_CONTINUE
Status in linux package in Ubuntu:
In Progress
Bug description:
SRU Justification
Impact: Recently we landed seccomp support for SECCOMP_RET_USER_NOTIF
(cf. [4]) which enables a process (watchee) to retrieve an fd for its
seccomp filter. This fd can then be handed to another (usually more
privileged) process (watcher). The watcher will then be able to
receive seccomp messages about the syscalls having been performed by
the watchee.
This feature is heavily used in some userspace workloads. For example,
it is currently used to intercept mknod() syscalls in user namespaces
aka in containers. The mknod() syscall can be easily filtered based on
dev_t. This allows us to only intercept a very specific subset of
mknod() syscalls. Furthermore, mknod() is not possible in user
namespaces toto coelo and so intercepting and denying syscalls that
are not in the whitelist on accident is not a big deal. The watchee
won't notice a difference.
In contrast to mknod(), a lot of other syscall we intercept (e.g. setxattr())
cannot be easily filtered like mknod() because they have pointer arguments.
Additionally, some of them might actually succeed in user namespaces (e.g.
setxattr() for all "user.*" xattrs). Since we currently cannot tell seccomp to
continue from a user notifier we are stuck with performing all of the syscalls
in lieu of the container. This is a huge security liability since it is
extreme
[Kernel-packages] [Bug 1836912] Re: ipv4: enable route flushing in network namespaces
** Tags removed: verification-needed-disco ** Tags added: verification-done-disco ** Changed in: linux (Ubuntu) Assignee: (unassigned) => Christian Brauner (cbrauner) ** Changed in: linux (Ubuntu Disco) Assignee: (unassigned) => Christian Brauner (cbrauner) -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1836912 Title: ipv4: enable route flushing in network namespaces Status in linux package in Ubuntu: Fix Released Status in linux source package in Disco: Fix Committed Bug description: SRU Justification Impact: Tools such as vpnc try to flush routes when run inside network namespaces by writing 1 into /proc/sys/net/ipv4/route/flush. This currently does not work because flush is not enabled in non-initial network namespaces. Users have complained about this at various times (cf. Link: https://github.com/lxc/lxd/issues/4257). Fix: Enable /proc/sys/net/ipv4/route/flush inside non-initial network namespaces. Regression Potential: None, since this didn't use to work before. Since routes are per network namespace it is safe to enable /proc/sys/net/ipv4/route/flush in there. Test Case: Tested with LXD on a kernel with the patch applied and by running vpnc successfully. Target Kernels: All LTS kernels starting from 4.15. Kernel 5.3 has the patchset upstream. Patches: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=5cdda5f1d6adde02da591ca2196f20289977dc56 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1836912/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1841977] Re: shiftfs: drop entries from cache on unlink
** Tags removed: verification-needed-disco ** Tags added: verification-done-disco ** Changed in: linux (Ubuntu Disco) Assignee: (unassigned) => Christian Brauner (cbrauner) -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1841977 Title: shiftfs: drop entries from cache on unlink Status in linux package in Ubuntu: Fix Released Status in linux source package in Disco: Fix Committed Bug description: SRU Justification Impact: LXD on Ubuntu runs on top of zfs by defaults. Users that make use of shiftfs for efficient id-shifting currently hit a bug where zfs is confused about the amount of space that is used in a dataset. For example, creating a file with 1GB of random data will increase the space used by the dataset by 1GB. When the file is removed via rm the space is not freed for zfs. This leads to zfs running out of space pretty quickly. This bug has been observed, described, and reproduced here https://discuss.linuxcontainers.org/t/trying-out-shiftfs/5155/9 . Stéphane Graber observed related issues. Regression Potential: Limited to shiftfs. This patch has been tested on various backends btrfs, dir, zfs to verify that it doesn't regress other workloads. Shiftfs now also aligns more closely with overlayfs on file deletion. Test Case: sudo snap install lxd sudo snap set lxd shiftfs.enable=true sudo systemctl restart snap.lxd.daemon sudo lxd init # make sure to select zfs as backend sudo lxc launch images:ubuntu/bionic b1 sudo lxc exec b1 -- dd if=/dev/urandom bs=1M count=1000 of=dummy.file sudo zfs list default/containers/b1 # will show +1GB sudo lxc exec b1 -- rm dummy.file sudo zfs list default/containers/b1 # will show +1GB on a non-fixed kernel and -1GB on a fixed kernel Target Kernels: All LTS kernels with shiftfs support. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1841977/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1842059] Re: shiftfs: mark kmem_cache as reclaimable
** Changed in: linux (Ubuntu Disco) Assignee: (unassigned) => Christian Brauner (cbrauner) ** Tags removed: verification-needed-disco ** Tags added: verification-done-disco -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1842059 Title: shiftfs: mark kmem_cache as reclaimable Status in linux package in Ubuntu: Fix Released Status in linux source package in Disco: Fix Committed Bug description: SRU Justification Impact: Shiftfs does not mark it's slab cache as reclaimable. While this is not a big deal it is not nice to the kernel in general. The shiftfs cache is not so important that it can't be reclaimed. Regression Potential: Limited to shiftfs. This patch has been tested for multiple days and has not caused any regressions. Test Case: Open a lot of files in shiftfs to get them into the cache and then cause memory pressure via e.g. stress-ng and see if the shiftfs cache shrinks. Target Kernels: All LTS kernels with shiftfs support. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1842059/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1846272] [NEW] overlayfs: allow with shiftfs as underlay
Public bug reported:
SRU Justification
Impact: Currently it is not possible to use overlayfs on top of shiftfs.
This means Docker inside of LXD cannot make user of the overlay2 graph
driver which is blocking users such as Travis from making use of it
efficiently.
Regression Potential: Limited to shiftfs and overlayfs on top of
shiftfs. Overlayfs does prevent "remote" filesystems such as ceph, nfs,
etc. from being used as the underlay. With this patch shiftfs however
can be used as an underlay and we special case it as a suitable
filesystem to be used under overlayfs. I verified that the patch does
not lead to regression on overlayfs workloads that do not make use of
shiftfs as underlay. Additionally, I tested Docker with the overlay2
graphdriver on top of shiftfs. This also has not lead to any
regressions.
Test case: Building a kernel with the patch:
sudo snap install lxd
sudo lxd init
sudo lxc launch images:ubuntu/bionic b1
sudo lxc config set b1 security.nesting true
sudo lxc restart --force b1
sudo lxc shell b1
sudo apt-get install \
apt-transport-https \
ca-certificates \
curl \
gnupg-agent \
software-properties-common
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -
curl -fsSL get.docker.com | CHANNEL=test sh
sudo add-apt-repository \
"deb [arch=amd64] https://download.docker.com/linux/ubuntu \
$(lsb_release -cs) \
stable"
sudo apt-get update
sudo apt-get install docker-ce docker-ce-cli containerd.io
sudo systemctl stop docker
cat <https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1838677 caused a
regression. The reproducer for this regression appended in
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1842382/comments/45
did show that the regression cannot be reproduced with the new patch.
Target kernels: All LTS kernels that do support shiftfs, if possible.
** Affects: linux (Ubuntu)
Importance: Undecided
Assignee: Christian Brauner (cbrauner)
Status: In Progress
** Changed in: linux (Ubuntu)
Assignee: (unassigned) => Christian Brauner (cbrauner)
** Changed in: linux (Ubuntu)
Status: New => In Progress
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1846272
Title:
overlayfs: allow with shiftfs as underlay
Status in linux package in Ubuntu:
In Progress
Bug description:
SRU Justification
Impact: Currently it is not possible to use overlayfs on top of
shiftfs. This means Docker inside of LXD cannot make user of the
overlay2 graph driver which is blocking users such as Travis from
making use of it efficiently.
Regression Potential: Limited to shiftfs and overlayfs on top of
shiftfs. Overlayfs does prevent "remote" filesystems such as ceph,
nfs, etc. from being used as the underlay. With this patch shiftfs
however can be used as an underlay and we special case it as a
suitable filesystem to be used under overlayfs. I verified that the
patch does not lead to regression on overlayfs workloads that do not
make use of shiftfs as underlay. Additionally, I tested Docker with
the overlay2 graphdriver on top of shiftfs. This also has not lead to
any regressions.
Test case: Building a kernel with the patch:
sudo snap install lxd
sudo lxd init
sudo lxc launch images:ubuntu/bionic b1
sudo lxc config set b1 security.nesting true
sudo lxc restart --force b1
sudo lxc shell b1
sudo apt-get install \
apt-transport-https \
ca-certificates \
curl \
gnupg-agent \
software-properties-common
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -
curl -fsSL get.docker.com | CHANNEL=test sh
sudo add-apt-repository \
"deb [arch=amd64] https://download.docker.com/linux/ubuntu \
$(lsb_release -cs) \
stable"
sudo apt-get update
sudo apt-get install docker-ce docker-ce-cli containerd.io
sudo systemctl stop docker
cat <https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1838677 caused a
regression. The reproducer for this regression appended in
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1842382/comments/45
did show that the regression cannot be reproduced with the new patch.
Target kernels: All LTS kernels that do support shiftfs, if possible.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1846272/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1846265] Re: shiftfs: rework how shiftfs opens files
** Changed in: linux (Ubuntu) Status: Incomplete => In Progress ** Changed in: linux (Ubuntu) Assignee: (unassigned) => Christian Brauner (cbrauner) -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1846265 Title: shiftfs: rework how shiftfs opens files Status in linux package in Ubuntu: In Progress Bug description: SRU Justification Impact: Currently, shiftfs maintains a kmem cache for struct shiftfs_file_info which stashes away a struct path and the struct file for the underlay. The path however is never used anywhere so the struct shiftfs_file_info and therefore the whole kmem cache can go away. This removes code and makes the whole logic simpler to understand and reason about. Fix: Remove the kmem cache for struct shiftfs_file_info and struct shiftfs_file_info itself and move to the same model as overlayfs and just stash away the struct file for the underlay in file->private_data of the shiftfs struct file Regression Potential: Limited to shiftfs. The basic logic is unchanged. It is just simplified so regression potential should be fairly low. Test Case: Tested with LXD on a kernel with the patch applied and running various standard workloads without any observable regressions. Target Kernels: All LTS kernels with support for shiftfs. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1846265/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1846265] [NEW] shiftfs: rework how shiftfs opens files
Public bug reported: SRU Justification Impact: Currently, shiftfs maintains a kmem cache for struct shiftfs_file_info which stashes away a struct path and the struct file for the underlay. The path however is never used anywhere so the struct shiftfs_file_info and therefore the whole kmem cache can go away. This removes code and makes the whole logic simpler to understand and reason about. Fix: Remove the kmem cache for struct shiftfs_file_info and struct shiftfs_file_info itself and move to the same model as overlayfs and just stash away the struct file for the underlay in file->private_data of the shiftfs struct file Regression Potential: Limited to shiftfs. The basic logic is unchanged. It is just simplified so regression potential should be fairly low. Test Case: Tested with LXD on a kernel with the patch applied and running various standard workloads without any observable regressions. Target Kernels: All LTS kernels with support for shiftfs. ** Affects: linux (Ubuntu) Importance: Undecided Status: Incomplete -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1846265 Title: shiftfs: rework how shiftfs opens files Status in linux package in Ubuntu: Incomplete Bug description: SRU Justification Impact: Currently, shiftfs maintains a kmem cache for struct shiftfs_file_info which stashes away a struct path and the struct file for the underlay. The path however is never used anywhere so the struct shiftfs_file_info and therefore the whole kmem cache can go away. This removes code and makes the whole logic simpler to understand and reason about. Fix: Remove the kmem cache for struct shiftfs_file_info and struct shiftfs_file_info itself and move to the same model as overlayfs and just stash away the struct file for the underlay in file->private_data of the shiftfs struct file Regression Potential: Limited to shiftfs. The basic logic is unchanged. It is just simplified so regression potential should be fairly low. Test Case: Tested with LXD on a kernel with the patch applied and running various standard workloads without any observable regressions. Target Kernels: All LTS kernels with support for shiftfs. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1846265/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1836910] Re: br_netfilter: namespace sysctl operations
** Tags removed: verification-needed-bionic ** Tags added: verification-done-bionic -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1836910 Title: br_netfilter: namespace sysctl operations Status in linux package in Ubuntu: Fix Released Status in linux source package in Bionic: Fix Committed Status in linux source package in Disco: Fix Released Bug description: SRU Justification Impact: Currently, the /proc/sys/net/bridge folder is only created in the initial network namespace. This blocks use-cases where users would like to e.g. not do bridge filtering for bridges in a specific network namespace while doing so for bridges located in another network namespace. Fix: The patches linked below ensure that the /proc/sys/net/bridge folder is available in each network namespace if the module is loaded and disappears from all network namespaces when the module is unloaded. In doing so the patch makes the sysctls: bridge-nf-call-arptables bridge-nf-call-ip6tables bridge-nf-call-iptables bridge-nf-filter-pppoe-tagged bridge-nf-filter-vlan-tagged bridge-nf-pass-vlan-input-dev apply per network namespace. Regression Potential: Low since it is limited to the br_netfilter module. I tested the patchset extensively by compiling a kernel with the patches applied. I loaded and unloaded the module and verified that it works correctly for the container usecase and does not crash. The Google ChromeOS team has also backported this patchset to their kernel and has not seen any issues so far: https://bugs.chromium.org/p/chromium/issues/detail?id=878034 Security considerations around netfilter rules are also low. The netfilter rules are already per network namespace so it should be safe for users to specify whether bridge devices inside a network namespace are supposed to go through iptables et al. or not. Also, this can already be done per-bridge by setting an option for each individual bridge via Netlink. It should also be possible to do this for all bridges in a network namespace via sysctls. Test Case: Tested with LXD on a kernel with the patches applied and per-network namespace iptables. Target Kernels: All LTS kernels starting from 4.15. Kernel 5.3 has the patchset upstream. Patches: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ff6d090d0db41425aef0cfe5dc58bb3cc12514a2 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=22567590b2e634247931b3d2351384ba45720ebe https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7e6daf50e1f4ea0ecd56406beb64ffc66e1e94db To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1836910/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1836912] Re: ipv4: enable route flushing in network namespaces
https://lists.ubuntu.com/archives/kernel-team/2019-September/103672.html -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1836912 Title: ipv4: enable route flushing in network namespaces Status in linux package in Ubuntu: Confirmed Bug description: SRU Justification Impact: Tools such as vpnc try to flush routes when run inside network namespaces by writing 1 into /proc/sys/net/ipv4/route/flush. This currently does not work because flush is not enabled in non-initial network namespaces. Users have complained about this at various times (cf. Link: https://github.com/lxc/lxd/issues/4257). Fix: Enable /proc/sys/net/ipv4/route/flush inside non-initial network namespaces. Regression Potential: None, since this didn't use to work before. Since routes are per network namespace it is safe to enable /proc/sys/net/ipv4/route/flush in there. Test Case: Tested with LXD on a kernel with the patch applied and by running vpnc successfully. Target Kernels: All LTS kernels starting from 4.15. Kernel 5.3 has the patchset upstream. Patches: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=5cdda5f1d6adde02da591ca2196f20289977dc56 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1836912/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1837223] Re: shiftfs: add O_DIRECT support
** Tags removed: verification-needed-disco ** Tags added: verification-done-disco -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1837223 Title: shiftfs: add O_DIRECT support Status in linux package in Ubuntu: Fix Released Status in linux source package in Disco: Fix Committed Bug description: SRU Justification Impact: Currently shiftfs does not handle O_DIRECT if the underlay supports it. This is blocking dqlite - an essential part of LXD - from profiting from the performance benefits of O_DIRECT on suitable filesystems when used with async io such as aio or io_uring. Regression Potential: Limited to shiftfs and virtually none since we have not supported this feature before. Test Case: Run LXD with dqlite on a kernel that has support for shiftfs with O_DIRECT. Target Kernels: All LTS kernels with shiftfs support. Patches: https://github.com/brauner/ubuntu-disco/tree/shiftfs_direct_io To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1837223/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1837231] Re: UBUNTU: SAUCE: shiftfs: pass correct point down
** Tags removed: verification-needed-disco ** Tags added: verification-done-disco -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1837231 Title: UBUNTU: SAUCE: shiftfs: pass correct point down Status in linux package in Ubuntu: Fix Released Status in linux source package in Disco: Fix Committed Bug description: SRU Justification Impact: shiftfs is currently passing down an unsigned long to copy_from_user() which expects a void __user * pointer. This will cause the compiler to complain because of mismatching types and in general is rather ugly. Regression Potential: Limited to shiftfs. Test Case: Compile kernel with patch and see that compiler does not complain anymore. Target Kernels: All LTS kernels with shiftfs support. Patches: https://github.com/brauner/ubuntu-disco/tree/shiftfs_direct_io To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1837231/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1836912] Re: ipv4: enable route flushing in network namespaces
See https://lists.ubuntu.com/archives/kernel-team/2019-September/103670.html -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1836912 Title: ipv4: enable route flushing in network namespaces Status in linux package in Ubuntu: Confirmed Bug description: SRU Justification Impact: Tools such as vpnc try to flush routes when run inside network namespaces by writing 1 into /proc/sys/net/ipv4/route/flush. This currently does not work because flush is not enabled in non-initial network namespaces. Users have complained about this at various times (cf. Link: https://github.com/lxc/lxd/issues/4257). Fix: Enable /proc/sys/net/ipv4/route/flush inside non-initial network namespaces. Regression Potential: None, since this didn't use to work before. Since routes are per network namespace it is safe to enable /proc/sys/net/ipv4/route/flush in there. Test Case: Tested with LXD on a kernel with the patch applied and by running vpnc successfully. Target Kernels: All LTS kernels starting from 4.15. Kernel 5.3 has the patchset upstream. Patches: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=5cdda5f1d6adde02da591ca2196f20289977dc56 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1836912/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1842059] [NEW] shiftfs: mark kmem_cache as reclaimable
Public bug reported: SRU Justification Impact: Shiftfs does not mark it's slab cache as reclaimable. While this is not a big deal it is not nice to the kernel in general. The shiftfs cache is not so important that it can't be reclaimed. Regression Potential: Limited to shiftfs. This patch has been tested for multiple days and has not caused any regressions. Test Case: Open a lot of files in shiftfs to get them into the cache and then cause memory pressure via e.g. stress-ng and see if the shiftfs cache shrinks. Target Kernels: All LTS kernels with shiftfs support. ** Affects: linux (Ubuntu) Importance: Undecided Assignee: Christian Brauner (cbrauner) Status: In Progress ** Changed in: linux (Ubuntu) Status: New => In Progress ** Changed in: linux (Ubuntu) Assignee: (unassigned) => Christian Brauner (cbrauner) -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1842059 Title: shiftfs: mark kmem_cache as reclaimable Status in linux package in Ubuntu: In Progress Bug description: SRU Justification Impact: Shiftfs does not mark it's slab cache as reclaimable. While this is not a big deal it is not nice to the kernel in general. The shiftfs cache is not so important that it can't be reclaimed. Regression Potential: Limited to shiftfs. This patch has been tested for multiple days and has not caused any regressions. Test Case: Open a lot of files in shiftfs to get them into the cache and then cause memory pressure via e.g. stress-ng and see if the shiftfs cache shrinks. Target Kernels: All LTS kernels with shiftfs support. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1842059/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1841977] [NEW] shiftfs: drop entries from cache on unlink
Public bug reported: SRU Justification Impact: LXD on Ubuntu runs on top of zfs by defaults. Users that make use of shiftfs for efficient id-shifting currently hit a bug where zfs is confused about the amount of space that is used in a dataset. For example, creating a file with 1GB of random data will increase the space used by the dataset by 1GB. When the file is removed via rm the space is not freed for zfs. This leads to zfs running out of space pretty quickly. This bug has been observed, described, and reproduced here https://discuss.linuxcontainers.org/t/trying-out-shiftfs/5155/9 . Stéphane Graber observed related issues. Regression Potential: Limited to shiftfs. This patch has been tested on various backends btrfs, dir, zfs to verify that it doesn't regress other workloads. Shiftfs now also aligns more closely with overlayfs on file deletion. Test Case: sudo snap install lxd sudo snap set lxd shiftfs.enable=true sudo systemctl restart snap.lxd.daemon sudo lxd init # make sure to select zfs as backend sudo lxc launch images:ubuntu/bionic b1 sudo lxc exec b1 -- dd if=/dev/urandom bs=1M count=1000 of=dummy.file sudo zfs list default/containers/b1 # will show +1GB sudo lxc exec b1 -- rm dummy.file sudo zfs list default/containers/b1 # will show +1GB on a non-fixed kernel and -1GB on a fixed kernel Target Kernels: All LTS kernels with shiftfs support. ** Affects: linux (Ubuntu) Importance: Undecided Assignee: Christian Brauner (cbrauner) Status: In Progress ** Changed in: linux (Ubuntu) Assignee: (unassigned) => Christian Brauner (cbrauner) ** Changed in: linux (Ubuntu) Status: New => In Progress -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1841977 Title: shiftfs: drop entries from cache on unlink Status in linux package in Ubuntu: In Progress Bug description: SRU Justification Impact: LXD on Ubuntu runs on top of zfs by defaults. Users that make use of shiftfs for efficient id-shifting currently hit a bug where zfs is confused about the amount of space that is used in a dataset. For example, creating a file with 1GB of random data will increase the space used by the dataset by 1GB. When the file is removed via rm the space is not freed for zfs. This leads to zfs running out of space pretty quickly. This bug has been observed, described, and reproduced here https://discuss.linuxcontainers.org/t/trying-out-shiftfs/5155/9 . Stéphane Graber observed related issues. Regression Potential: Limited to shiftfs. This patch has been tested on various backends btrfs, dir, zfs to verify that it doesn't regress other workloads. Shiftfs now also aligns more closely with overlayfs on file deletion. Test Case: sudo snap install lxd sudo snap set lxd shiftfs.enable=true sudo systemctl restart snap.lxd.daemon sudo lxd init # make sure to select zfs as backend sudo lxc launch images:ubuntu/bionic b1 sudo lxc exec b1 -- dd if=/dev/urandom bs=1M count=1000 of=dummy.file sudo zfs list default/containers/b1 # will show +1GB sudo lxc exec b1 -- rm dummy.file sudo zfs list default/containers/b1 # will show +1GB on a non-fixed kernel and -1GB on a fixed kernel Target Kernels: All LTS kernels with shiftfs support. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1841977/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1838677] Re: shiftfs: allow overlayfs
** Tags removed: verification-needed-bionic ** Tags added: verification-done-bionic -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1838677 Title: shiftfs: allow overlayfs Status in linux package in Ubuntu: Fix Committed Status in linux source package in Disco: Fix Committed Bug description: SRU Justification Impact: Currently it is not possible to use overlayfs on top of shiftfs. This means Docker inside of LXD cannot make user of the overlay2 graph driver which is blocking users such as Travis from making use of it efficiently. Regression Potential: Limited to shiftfs and overlayfs on top of shiftfs. Overlayfs does prevent "remote" filesystems such as ceph, nfs, etc. from being used as the underlay. With this patch shiftfs however can be used as an underlay and we special case it as a suitable filesystem to be used under overlayfs. I verified that the patch does not lead to regression on overlayfs workloads that do not make use of shiftfs as underlay. Additionally, I tested Docker with the overlay2 graphdriver on top of shiftfs. This also has not lead to any regressions. Test case: Building a kernel with the patch: sudo snap install lxd sudo lxd init sudo lxc launch images:ubuntu/bionic b1 sudo lxc config set b1 security.nesting true sudo lxc restart --force b1 sudo lxc shell b1 sudo apt-get install \ apt-transport-https \ ca-certificates \ curl \ gnupg-agent \ software-properties-common curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add - curl -fsSL get.docker.com | CHANNEL=test sh sudo add-apt-repository \ "deb [arch=amd64] https://download.docker.com/linux/ubuntu \ $(lsb_release -cs) \ stable" sudo apt-get update sudo apt-get install docker-ce docker-ce-cli containerd.io sudo systemctl stop docker cat
[Kernel-packages] [Bug 1836910] Re: br_netfilter: namespace sysctl operations
** Tags removed: verification-needed-bionic verification-needed-disco ** Tags added: verification-done-bionic verification-done-disco -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1836910 Title: br_netfilter: namespace sysctl operations Status in linux package in Ubuntu: Fix Released Status in linux source package in Bionic: In Progress Status in linux source package in Disco: Fix Committed Bug description: SRU Justification Impact: Currently, the /proc/sys/net/bridge folder is only created in the initial network namespace. This blocks use-cases where users would like to e.g. not do bridge filtering for bridges in a specific network namespace while doing so for bridges located in another network namespace. Fix: The patches linked below ensure that the /proc/sys/net/bridge folder is available in each network namespace if the module is loaded and disappears from all network namespaces when the module is unloaded. In doing so the patch makes the sysctls: bridge-nf-call-arptables bridge-nf-call-ip6tables bridge-nf-call-iptables bridge-nf-filter-pppoe-tagged bridge-nf-filter-vlan-tagged bridge-nf-pass-vlan-input-dev apply per network namespace. Regression Potential: Low since it is limited to the br_netfilter module. I tested the patchset extensively by compiling a kernel with the patches applied. I loaded and unloaded the module and verified that it works correctly for the container usecase and does not crash. The Google ChromeOS team has also backported this patchset to their kernel and has not seen any issues so far: https://bugs.chromium.org/p/chromium/issues/detail?id=878034 Security considerations around netfilter rules are also low. The netfilter rules are already per network namespace so it should be safe for users to specify whether bridge devices inside a network namespace are supposed to go through iptables et al. or not. Also, this can already be done per-bridge by setting an option for each individual bridge via Netlink. It should also be possible to do this for all bridges in a network namespace via sysctls. Test Case: Tested with LXD on a kernel with the patches applied and per-network namespace iptables. Target Kernels: All LTS kernels starting from 4.15. Kernel 5.3 has the patchset upstream. Patches: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ff6d090d0db41425aef0cfe5dc58bb3cc12514a2 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=22567590b2e634247931b3d2351384ba45720ebe https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7e6daf50e1f4ea0ecd56406beb64ffc66e1e94db To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1836910/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1838677] Re: shiftfs: allow overlayfs
** Tags removed: verification-needed-disco ** Tags added: verification-done-disco -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1838677 Title: shiftfs: allow overlayfs Status in linux package in Ubuntu: Fix Committed Status in linux source package in Disco: Fix Committed Bug description: SRU Justification Impact: Currently it is not possible to use overlayfs on top of shiftfs. This means Docker inside of LXD cannot make user of the overlay2 graph driver which is blocking users such as Travis from making use of it efficiently. Regression Potential: Limited to shiftfs and overlayfs on top of shiftfs. Overlayfs does prevent "remote" filesystems such as ceph, nfs, etc. from being used as the underlay. With this patch shiftfs however can be used as an underlay and we special case it as a suitable filesystem to be used under overlayfs. I verified that the patch does not lead to regression on overlayfs workloads that do not make use of shiftfs as underlay. Additionally, I tested Docker with the overlay2 graphdriver on top of shiftfs. This also has not lead to any regressions. Test case: Building a kernel with the patch: sudo snap install lxd sudo lxd init sudo lxc launch images:ubuntu/bionic b1 sudo lxc config set b1 security.nesting true sudo lxc restart --force b1 sudo lxc shell b1 sudo apt-get install \ apt-transport-https \ ca-certificates \ curl \ gnupg-agent \ software-properties-common curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add - curl -fsSL get.docker.com | CHANNEL=test sh sudo add-apt-repository \ "deb [arch=amd64] https://download.docker.com/linux/ubuntu \ $(lsb_release -cs) \ stable" sudo apt-get update sudo apt-get install docker-ce docker-ce-cli containerd.io sudo systemctl stop docker cat
[Kernel-packages] [Bug 1824719] Re: shiftfs: Allow stacking overlayfs on top
SRU request here: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1838677 Patchset here: https://github.com/brauner/ubuntu-disco/tree/overlayfs_on_shiftfs Mailing list patchset posting here: https://lists.ubuntu.com/archives/kernel-team/2019-August/102741.html ** Changed in: linux (Ubuntu) Status: Triaged => In Progress -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1824719 Title: shiftfs: Allow stacking overlayfs on top Status in linux package in Ubuntu: In Progress Bug description: Shiftfs right now prevents stacking overlayfs on top of it which unfortunately means all users of Docker as well as some nested LXC users which aren't using btrfs are going to break when they get switched over to shiftfs. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1824719/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1838677] Re: shiftfs: allow overlayfs
SRU request here: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1838677 Patchset here: https://github.com/brauner/ubuntu-disco/tree/overlayfs_on_shiftfs Mailing list patchset posting here: https://lists.ubuntu.com/archives/kernel-team/2019-August/102741.html ** Tags added: shiftfs -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1838677 Title: shiftfs: allow overlayfs Status in linux package in Ubuntu: In Progress Bug description: SRU Justification Impact: Currently it is not possible to use overlayfs on top of shiftfs. This means Docker inside of LXD cannot make user of the overlay2 graph driver which is blocking users such as Travis from making use of it efficiently. Regression Potential: Limited to shiftfs and overlayfs on top of shiftfs. Overlayfs does prevent "remote" filesystems such as ceph, nfs, etc. from being used as the underlay. With this patch shiftfs however can be used as an underlay and we special case it as a suitable filesystem to be used under overlayfs. I verified that the patch does not lead to regression on overlayfs workloads that do not make use of shiftfs as underlay. Additionally, I tested Docker with the overlay2 graphdriver on top of shiftfs. This also has not lead to any regressions. Test case: Building a kernel with the patch: sudo snap install lxd sudo lxd init sudo lxc launch images:ubuntu/bionic b1 sudo lxc config set b1 security.nesting true sudo lxc restart --force b1 sudo lxc shell b1 sudo apt-get install \ apt-transport-https \ ca-certificates \ curl \ gnupg-agent \ software-properties-common curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add - curl -fsSL get.docker.com | CHANNEL=test sh sudo add-apt-repository \ "deb [arch=amd64] https://download.docker.com/linux/ubuntu \ $(lsb_release -cs) \ stable" sudo apt-get update sudo apt-get install docker-ce docker-ce-cli containerd.io sudo systemctl stop docker cat
[Kernel-packages] [Bug 1838677] [NEW] shiftfs: allow overlayfs
Public bug reported: SRU Justification Impact: Currently it is not possible to use overlayfs on top of shiftfs. This means Docker inside of LXD cannot make user of the overlay2 graph driver which is blocking users such as Travis from making use of it efficiently. Regression Potential: Limited to shiftfs and overlayfs on top of shiftfs. Overlayfs does prevent "remote" filesystems such as ceph, nfs, etc. from being used as the underlay. With this patch shiftfs however can be used as an underlay and we special case it as a suitable filesystem to be used under overlayfs. I verified that the patch does not lead to regression on overlayfs workloads that do not make use of shiftfs as underlay. Additionally, I tested Docker with the overlay2 graphdriver on top of shiftfs. This also has not lead to any regressions. Test case: Building a kernel with the patch: sudo snap install lxd sudo lxd init sudo lxc launch images:ubuntu/bionic b1 sudo lxc config set b1 security.nesting true sudo lxc restart --force b1 sudo lxc shell b1 sudo apt-get install \ apt-transport-https \ ca-certificates \ curl \ gnupg-agent \ software-properties-common curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add - curl -fsSL get.docker.com | CHANNEL=test sh sudo add-apt-repository \ "deb [arch=amd64] https://download.docker.com/linux/ubuntu \ $(lsb_release -cs) \ stable" sudo apt-get update sudo apt-get install docker-ce docker-ce-cli containerd.io sudo systemctl stop docker cat < Christian Brauner (cbrauner) ** Changed in: linux (Ubuntu) Status: New => Confirmed ** Changed in: linux (Ubuntu) Status: Confirmed => In Progress -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1838677 Title: shiftfs: allow overlayfs Status in linux package in Ubuntu: In Progress Bug description: SRU Justification Impact: Currently it is not possible to use overlayfs on top of shiftfs. This means Docker inside of LXD cannot make user of the overlay2 graph driver which is blocking users such as Travis from making use of it efficiently. Regression Potential: Limited to shiftfs and overlayfs on top of shiftfs. Overlayfs does prevent "remote" filesystems such as ceph, nfs, etc. from being used as the underlay. With this patch shiftfs however can be used as an underlay and we special case it as a suitable filesystem to be used under overlayfs. I verified that the patch does not lead to regression on overlayfs workloads that do not make use of shiftfs as underlay. Additionally, I tested Docker with the overlay2 graphdriver on top of shiftfs. This also has not lead to any regressions. Test case: Building a kernel with the patch: sudo snap install lxd sudo lxd init sudo lxc launch images:ubuntu/bionic b1 sudo lxc config set b1 security.nesting true sudo lxc restart --force b1 sudo lxc shell b1 sudo apt-get install \ apt-transport-https \ ca-certificates \ curl \ gnupg-agent \ software-properties-common curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add - curl -fsSL get.docker.com | CHANNEL=test sh sudo add-apt-repository \ "deb [arch=amd64] https://download.docker.com/linux/ubuntu \ $(lsb_release -cs) \ stable" sudo apt-get update sudo apt-get install docker-ce docker-ce-cli containerd.io sudo systemctl stop docker cat <https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1838677/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1836910] Re: br_netfilter: namespace sysctl operations
** Description changed: SRU Justification Impact: Currently, the /proc/sys/net/bridge folder is only created in the initial network namespace. This blocks use-cases where users would like to e.g. not do bridge filtering for bridges in a specific network namespace while doing so for bridges located in another network namespace. Fix: The patches linked below ensure that the /proc/sys/net/bridge folder is available in each network namespace if the module is loaded and disappears from all network namespaces when the module is unloaded. In doing so the patch makes the sysctls: bridge-nf-call-arptables bridge-nf-call-ip6tables bridge-nf-call-iptables bridge-nf-filter-pppoe-tagged bridge-nf-filter-vlan-tagged bridge-nf-pass-vlan-input-dev apply per network namespace. - Regression Potential: Low since it is limited to the br_netfilter module. - I verified that this does not lead to any regressions by compiling a kernel with those patches. I loaded and unloaded the module and verified that it works correctly for the container usecase and does not crash. - The netfilter rules are afaict already per network namespace so it should be safe for users to specify whether bridge devices inside a network namespace are supposed to go through iptables et al. or not. Also, this can already be done per-bridge by setting an option for each individual bridge via Netlink. It should also be possible to do this for all bridges in a network namespace via sysctls. + Regression Potential: Low since it is limited to the br_netfilter module. I tested the patchset extensively by compiling a kernel with the patches applied. I loaded and unloaded the module and verified that it works correctly for the container usecase and does not crash. The Google ChromeOS team has also backported this patchset to their kernel and has not seen any issues so far: https://bugs.chromium.org/p/chromium/issues/detail?id=878034 + Security considerations around netfilter rules are also low. The netfilter rules are already per network namespace so it should be safe for users to specify whether bridge devices inside a network namespace are supposed to go through iptables et al. or not. Also, this can already be done per-bridge by setting an option for each individual bridge via Netlink. It should also be possible to do this for all bridges in a network namespace via sysctls. Test Case: Tested with LXD on a kernel with the patches applied and per- network namespace iptables. Target Kernels: All LTS kernels starting from 4.15. Kernel 5.3 has the patchset upstream. Patches: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ff6d090d0db41425aef0cfe5dc58bb3cc12514a2 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=22567590b2e634247931b3d2351384ba45720ebe https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7e6daf50e1f4ea0ecd56406beb64ffc66e1e94db -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1836910 Title: br_netfilter: namespace sysctl operations Status in linux package in Ubuntu: Fix Committed Status in linux source package in Bionic: In Progress Status in linux source package in Disco: In Progress Bug description: SRU Justification Impact: Currently, the /proc/sys/net/bridge folder is only created in the initial network namespace. This blocks use-cases where users would like to e.g. not do bridge filtering for bridges in a specific network namespace while doing so for bridges located in another network namespace. Fix: The patches linked below ensure that the /proc/sys/net/bridge folder is available in each network namespace if the module is loaded and disappears from all network namespaces when the module is unloaded. In doing so the patch makes the sysctls: bridge-nf-call-arptables bridge-nf-call-ip6tables bridge-nf-call-iptables bridge-nf-filter-pppoe-tagged bridge-nf-filter-vlan-tagged bridge-nf-pass-vlan-input-dev apply per network namespace. Regression Potential: Low since it is limited to the br_netfilter module. I tested the patchset extensively by compiling a kernel with the patches applied. I loaded and unloaded the module and verified that it works correctly for the container usecase and does not crash. The Google ChromeOS team has also backported this patchset to their kernel and has not seen any issues so far: https://bugs.chromium.org/p/chromium/issues/detail?id=878034 Security considerations around netfilter rules are also low. The netfilter rules are already per network namespace so it should be safe for users to specify whether bridge devices inside a network namespace are supposed to go through iptables et al. or not. Also, this can already be done per-bridge by setting an option for each
[Kernel-packages] [Bug 1836910] Re: br_netfilter: namespace sysctl operations
** Description changed: SRU Justification Impact: Currently, the /proc/sys/net/bridge folder is only created in the initial network namespace. This blocks use-cases where users would like to e.g. not do bridge filtering for bridges in a specific network namespace while doing so for bridges located in another network namespace. Fix: The patches linked below ensure that the /proc/sys/net/bridge folder is available in each network namespace if the module is loaded and disappears from all network namespaces when the module is unloaded. In doing so the patch makes the sysctls: bridge-nf-call-arptables bridge-nf-call-ip6tables bridge-nf-call-iptables bridge-nf-filter-pppoe-tagged bridge-nf-filter-vlan-tagged bridge-nf-pass-vlan-input-dev apply per network namespace. - Regression Potential: None, since this didn't use to work before. Otherwise limited to the br_netfilter module. + Regression Potential: Low since it is limited to the br_netfilter module. + I verified that this does not lead to any regressions by compiling a kernel with those patches. I loaded and unloaded the module and verified that it works correctly for the container usecase and does not crash. The netfilter rules are afaict already per network namespace so it should be safe for users to specify whether bridge devices inside a network namespace are supposed to go through iptables et al. or not. Also, this can already be done per-bridge by setting an option for each individual bridge via Netlink. It should also be possible to do this for all bridges in a network namespace via sysctls. Test Case: Tested with LXD on a kernel with the patches applied and per- network namespace iptables. Target Kernels: All LTS kernels starting from 4.15. Kernel 5.3 has the patchset upstream. Patches: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ff6d090d0db41425aef0cfe5dc58bb3cc12514a2 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=22567590b2e634247931b3d2351384ba45720ebe https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7e6daf50e1f4ea0ecd56406beb64ffc66e1e94db -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1836910 Title: br_netfilter: namespace sysctl operations Status in linux package in Ubuntu: Fix Committed Status in linux source package in Bionic: In Progress Status in linux source package in Disco: In Progress Bug description: SRU Justification Impact: Currently, the /proc/sys/net/bridge folder is only created in the initial network namespace. This blocks use-cases where users would like to e.g. not do bridge filtering for bridges in a specific network namespace while doing so for bridges located in another network namespace. Fix: The patches linked below ensure that the /proc/sys/net/bridge folder is available in each network namespace if the module is loaded and disappears from all network namespaces when the module is unloaded. In doing so the patch makes the sysctls: bridge-nf-call-arptables bridge-nf-call-ip6tables bridge-nf-call-iptables bridge-nf-filter-pppoe-tagged bridge-nf-filter-vlan-tagged bridge-nf-pass-vlan-input-dev apply per network namespace. Regression Potential: Low since it is limited to the br_netfilter module. I verified that this does not lead to any regressions by compiling a kernel with those patches. I loaded and unloaded the module and verified that it works correctly for the container usecase and does not crash. The netfilter rules are afaict already per network namespace so it should be safe for users to specify whether bridge devices inside a network namespace are supposed to go through iptables et al. or not. Also, this can already be done per-bridge by setting an option for each individual bridge via Netlink. It should also be possible to do this for all bridges in a network namespace via sysctls. Test Case: Tested with LXD on a kernel with the patches applied and per-network namespace iptables. Target Kernels: All LTS kernels starting from 4.15. Kernel 5.3 has the patchset upstream. Patches: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ff6d090d0db41425aef0cfe5dc58bb3cc12514a2 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=22567590b2e634247931b3d2351384ba45720ebe https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7e6daf50e1f4ea0ecd56406beb64ffc66e1e94db To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1836910/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help :
[Kernel-packages] [Bug 1837231] [NEW] UBUNTU: SAUCE: shiftfs: pass correct point down
Public bug reported: SRU Justification Impact: shiftfs is currently passing down an unsigned long to copy_from_user() which expects a void __user * pointer. This will cause the compiler to complain because of mismatching types and in general is rather ugly. Regression Potential: Limited to shiftfs. Test Case: Compile kernel with patch and see that compiler does not complain anymore. Target Kernels: All LTS kernels with shiftfs support. Patches: https://github.com/brauner/ubuntu-disco/tree/shiftfs_direct_io ** Affects: linux (Ubuntu) Importance: Undecided Assignee: Christian Brauner (cbrauner) Status: In Progress ** Changed in: linux (Ubuntu) Assignee: (unassigned) => Christian Brauner (cbrauner) ** Changed in: linux (Ubuntu) Status: New => In Progress -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1837231 Title: UBUNTU: SAUCE: shiftfs: pass correct point down Status in linux package in Ubuntu: In Progress Bug description: SRU Justification Impact: shiftfs is currently passing down an unsigned long to copy_from_user() which expects a void __user * pointer. This will cause the compiler to complain because of mismatching types and in general is rather ugly. Regression Potential: Limited to shiftfs. Test Case: Compile kernel with patch and see that compiler does not complain anymore. Target Kernels: All LTS kernels with shiftfs support. Patches: https://github.com/brauner/ubuntu-disco/tree/shiftfs_direct_io To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1837231/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1837223] Re: shiftfs: add O_DIRECT support
** Changed in: linux (Ubuntu) Status: Confirmed => In Progress -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1837223 Title: shiftfs: add O_DIRECT support Status in linux package in Ubuntu: In Progress Bug description: SRU Justification Impact: Currently shiftfs does not handle O_DIRECT if the underlay supports it. This is blocking dqlite - an essential part of LXD - from profiting from the performance benefits of O_DIRECT on suitable filesystems when used with async io such as aio or io_uring. Regression Potential: Limited to shiftfs and virtually none since we have not supported this feature before. Test Case: Run LXD with dqlite on a kernel that has support for shiftfs with O_DIRECT. Target Kernels: All LTS kernels with shiftfs support. Patches: https://github.com/brauner/ubuntu-disco/tree/shiftfs_direct_io To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1837223/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1837223] [NEW] shiftfs: add O_DIRECT support
Public bug reported: SRU Justification Impact: Currently shiftfs does not handle O_DIRECT if the underlay supports it. This is blocking dqlite - an essential part of LXD - from profiting from the performance benefits of O_DIRECT on suitable filesystems when used with async io such as aio or io_uring. Regression Potential: Limited to shiftfs and virtually none since we have not supported this feature before. Test Case: Run LXD with dqlite on a kernel that has support for shiftfs with O_DIRECT. Target Kernels: All LTS kernels with shiftfs support. Patches: https://github.com/brauner/ubuntu-disco/tree/shiftfs_direct_io ** Affects: linux (Ubuntu) Importance: Undecided Assignee: Christian Brauner (cbrauner) Status: Confirmed ** Changed in: linux (Ubuntu) Status: New => Confirmed ** Changed in: linux (Ubuntu) Assignee: (unassigned) => Christian Brauner (cbrauner) -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1837223 Title: shiftfs: add O_DIRECT support Status in linux package in Ubuntu: Confirmed Bug description: SRU Justification Impact: Currently shiftfs does not handle O_DIRECT if the underlay supports it. This is blocking dqlite - an essential part of LXD - from profiting from the performance benefits of O_DIRECT on suitable filesystems when used with async io such as aio or io_uring. Regression Potential: Limited to shiftfs and virtually none since we have not supported this feature before. Test Case: Run LXD with dqlite on a kernel that has support for shiftfs with O_DIRECT. Target Kernels: All LTS kernels with shiftfs support. Patches: https://github.com/brauner/ubuntu-disco/tree/shiftfs_direct_io To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1837223/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1725382] Re: unprivileged fuse mounts feature into the upstream kernel
** Changed in: linux (Ubuntu) Status: Triaged => Fix Released -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1725382 Title: unprivileged fuse mounts feature into the upstream kernel Status in linux package in Ubuntu: Fix Released Bug description: https://github.com/lxc/lxc/issues/1867 As of issue about Debian 9, Christian Brauner concluded "unprivileged fuse mounts is a feature available in the Ubuntu kernel only atm. We are actively working on pushing this into the upstream kernel though" Please, conclude this issue when it's done. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1725382/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1836912] Re: ipv4: enable route flushing in network namespaces
** Description changed: - Tools such as vpnc try to flush routes when run inside network - namespaces by writing 1 into /proc/sys/net/ipv4/route/flush. This - currently does not work because flush is not enabled in non-initial - network namespaces. - Since routes are per network namespace it is safe to enable + SRU Justification + + Impact: Tools such as vpnc try to flush routes when run inside network namespaces by writing 1 into /proc/sys/net/ipv4/route/flush. This + currently does not work because flush is not enabled in non-initial network namespaces. Users have complained about this at various times (cf. Link: https://github.com/lxc/lxd/issues/4257). + + Fix: Enable /proc/sys/net/ipv4/route/flush inside non-initial network + namespaces. + + Regression Potential: None, since this didn't use to work before. Since + routes are per network namespace it is safe to enable /proc/sys/net/ipv4/route/flush in there. - This has been reported against LXD a few times before + Test Case: Tested with LXD on a kernel with the patch applied and by + running vpnc successfully. - Link: https://github.com/lxc/lxd/issues/4257 + Target Kernels: All LTS kernels starting from 4.15. Kernel 5.3 has the + patchset upstream. - Please backport this to our LTS kernels. :) + Patches: + https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=5cdda5f1d6adde02da591ca2196f20289977dc56 -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1836912 Title: ipv4: enable route flushing in network namespaces Status in linux package in Ubuntu: Confirmed Bug description: SRU Justification Impact: Tools such as vpnc try to flush routes when run inside network namespaces by writing 1 into /proc/sys/net/ipv4/route/flush. This currently does not work because flush is not enabled in non-initial network namespaces. Users have complained about this at various times (cf. Link: https://github.com/lxc/lxd/issues/4257). Fix: Enable /proc/sys/net/ipv4/route/flush inside non-initial network namespaces. Regression Potential: None, since this didn't use to work before. Since routes are per network namespace it is safe to enable /proc/sys/net/ipv4/route/flush in there. Test Case: Tested with LXD on a kernel with the patch applied and by running vpnc successfully. Target Kernels: All LTS kernels starting from 4.15. Kernel 5.3 has the patchset upstream. Patches: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=5cdda5f1d6adde02da591ca2196f20289977dc56 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1836912/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1836910] Re: br_netfilter: namespace sysctl operations
** Description changed: - Currently, the /proc/sys/net/bridge folder is only created in the initial - network namespace. This patch ensures that the /proc/sys/net/bridge folder - is available in each network namespace if the module is loaded and - disappears from all network namespaces when the module is unloaded. + SRU Justification + + Impact: Currently, the /proc/sys/net/bridge folder is only created in + the initial network namespace. This blocks use-cases where users would + like to e.g. not do bridge filtering for bridges in a specific network + namespace while doing so for bridges located in another network + namespace. + + Fix: The patches linked below ensure that the /proc/sys/net/bridge + folder is available in each network namespace if the module is loaded + and disappears from all network namespaces when the module is unloaded. In doing so the patch makes the sysctls: bridge-nf-call-arptables bridge-nf-call-ip6tables bridge-nf-call-iptables bridge-nf-filter-pppoe-tagged bridge-nf-filter-vlan-tagged bridge-nf-pass-vlan-input-dev - apply per network namespace. This unblocks some use-cases where users would - like to e.g. not do bridge filtering for bridges in a specific network - namespace while doing so for bridges located in another network namespace. + apply per network namespace. - The netfilter rules are afaict already per network namespace so it should - be safe for users to specify whether bridge devices inside a network - namespace are supposed to go through iptables et al. or not. Also, this can - already be done per-bridge by setting an option for each individual bridge - via Netlink. It should also be possible to do this for all bridges in a - network namespace via sysctls. + Regression Potential: None, since this didn't use to work before. Otherwise limited to the br_netfilter module. + The netfilter rules are afaict already per network namespace so it should be safe for users to specify whether bridge devices inside a network namespace are supposed to go through iptables et al. or not. Also, this can already be done per-bridge by setting an option for each individual bridge via Netlink. It should also be possible to do this for all bridges in a network namespace via sysctls. - I've pushed a small series of patches upstream. - Please backport them to our LTS kernels. :) + Test Case: Tested with LXD on a kernel with the patches applied and per- + network namespace iptables. + + Target Kernels: All LTS kernels starting from 4.15. Kernel 5.3 has the + patchset upstream. + + Patches: + https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ff6d090d0db41425aef0cfe5dc58bb3cc12514a2 + + https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=22567590b2e634247931b3d2351384ba45720ebe + + https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7e6daf50e1f4ea0ecd56406beb64ffc66e1e94db -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1836910 Title: br_netfilter: namespace sysctl operations Status in linux package in Ubuntu: Confirmed Bug description: SRU Justification Impact: Currently, the /proc/sys/net/bridge folder is only created in the initial network namespace. This blocks use-cases where users would like to e.g. not do bridge filtering for bridges in a specific network namespace while doing so for bridges located in another network namespace. Fix: The patches linked below ensure that the /proc/sys/net/bridge folder is available in each network namespace if the module is loaded and disappears from all network namespaces when the module is unloaded. In doing so the patch makes the sysctls: bridge-nf-call-arptables bridge-nf-call-ip6tables bridge-nf-call-iptables bridge-nf-filter-pppoe-tagged bridge-nf-filter-vlan-tagged bridge-nf-pass-vlan-input-dev apply per network namespace. Regression Potential: None, since this didn't use to work before. Otherwise limited to the br_netfilter module. The netfilter rules are afaict already per network namespace so it should be safe for users to specify whether bridge devices inside a network namespace are supposed to go through iptables et al. or not. Also, this can already be done per-bridge by setting an option for each individual bridge via Netlink. It should also be possible to do this for all bridges in a network namespace via sysctls. Test Case: Tested with LXD on a kernel with the patches applied and per-network namespace iptables. Target Kernels: All LTS kernels starting from 4.15. Kernel 5.3 has the patchset upstream. Patches: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ff6d090d0db41425aef0cfe5dc58bb3cc12514a2
[Kernel-packages] [Bug 1836910] Re: br_netfilter: namespace sysctl operations
Relevant upstream commits are: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ff6d090d0db41425aef0cfe5dc58bb3cc12514a2 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=22567590b2e634247931b3d2351384ba45720ebe https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7e6daf50e1f4ea0ecd56406beb64ffc66e1e94db -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1836910 Title: br_netfilter: namespace sysctl operations Status in linux package in Ubuntu: Confirmed Bug description: Currently, the /proc/sys/net/bridge folder is only created in the initial network namespace. This patch ensures that the /proc/sys/net/bridge folder is available in each network namespace if the module is loaded and disappears from all network namespaces when the module is unloaded. In doing so the patch makes the sysctls: bridge-nf-call-arptables bridge-nf-call-ip6tables bridge-nf-call-iptables bridge-nf-filter-pppoe-tagged bridge-nf-filter-vlan-tagged bridge-nf-pass-vlan-input-dev apply per network namespace. This unblocks some use-cases where users would like to e.g. not do bridge filtering for bridges in a specific network namespace while doing so for bridges located in another network namespace. The netfilter rules are afaict already per network namespace so it should be safe for users to specify whether bridge devices inside a network namespace are supposed to go through iptables et al. or not. Also, this can already be done per-bridge by setting an option for each individual bridge via Netlink. It should also be possible to do this for all bridges in a network namespace via sysctls. I've pushed a small series of patches upstream. Please backport them to our LTS kernels. :) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1836910/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1836912] Re: ipv4: enable route flushing in network namespaces
Relevant upstream commit is: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=5cdda5f1d6adde02da591ca2196f20289977dc56 ** Changed in: linux (Ubuntu) Status: New => Confirmed -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1836912 Title: ipv4: enable route flushing in network namespaces Status in linux package in Ubuntu: Confirmed Bug description: Tools such as vpnc try to flush routes when run inside network namespaces by writing 1 into /proc/sys/net/ipv4/route/flush. This currently does not work because flush is not enabled in non-initial network namespaces. Since routes are per network namespace it is safe to enable /proc/sys/net/ipv4/route/flush in there. This has been reported against LXD a few times before Link: https://github.com/lxc/lxd/issues/4257 Please backport this to our LTS kernels. :) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1836912/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1836910] Re: br_netfilter: namespace sysctl operations
** Changed in: linux (Ubuntu) Status: Incomplete => Confirmed -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1836910 Title: br_netfilter: namespace sysctl operations Status in linux package in Ubuntu: Confirmed Bug description: Currently, the /proc/sys/net/bridge folder is only created in the initial network namespace. This patch ensures that the /proc/sys/net/bridge folder is available in each network namespace if the module is loaded and disappears from all network namespaces when the module is unloaded. In doing so the patch makes the sysctls: bridge-nf-call-arptables bridge-nf-call-ip6tables bridge-nf-call-iptables bridge-nf-filter-pppoe-tagged bridge-nf-filter-vlan-tagged bridge-nf-pass-vlan-input-dev apply per network namespace. This unblocks some use-cases where users would like to e.g. not do bridge filtering for bridges in a specific network namespace while doing so for bridges located in another network namespace. The netfilter rules are afaict already per network namespace so it should be safe for users to specify whether bridge devices inside a network namespace are supposed to go through iptables et al. or not. Also, this can already be done per-bridge by setting an option for each individual bridge via Netlink. It should also be possible to do this for all bridges in a network namespace via sysctls. I've pushed a small series of patches upstream. Please backport them to our LTS kernels. :) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1836910/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1836912] [NEW] ipv4: enable route flushing in network namespaces
Public bug reported: Tools such as vpnc try to flush routes when run inside network namespaces by writing 1 into /proc/sys/net/ipv4/route/flush. This currently does not work because flush is not enabled in non-initial network namespaces. Since routes are per network namespace it is safe to enable /proc/sys/net/ipv4/route/flush in there. This has been reported against LXD a few times before Link: https://github.com/lxc/lxd/issues/4257 Please backport this to our LTS kernels. :) ** Affects: linux (Ubuntu) Importance: Undecided Status: Confirmed -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1836912 Title: ipv4: enable route flushing in network namespaces Status in linux package in Ubuntu: Confirmed Bug description: Tools such as vpnc try to flush routes when run inside network namespaces by writing 1 into /proc/sys/net/ipv4/route/flush. This currently does not work because flush is not enabled in non-initial network namespaces. Since routes are per network namespace it is safe to enable /proc/sys/net/ipv4/route/flush in there. This has been reported against LXD a few times before Link: https://github.com/lxc/lxd/issues/4257 Please backport this to our LTS kernels. :) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1836912/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1836910] [NEW] br_netfilter: namespace sysctl operations
Public bug reported: Currently, the /proc/sys/net/bridge folder is only created in the initial network namespace. This patch ensures that the /proc/sys/net/bridge folder is available in each network namespace if the module is loaded and disappears from all network namespaces when the module is unloaded. In doing so the patch makes the sysctls: bridge-nf-call-arptables bridge-nf-call-ip6tables bridge-nf-call-iptables bridge-nf-filter-pppoe-tagged bridge-nf-filter-vlan-tagged bridge-nf-pass-vlan-input-dev apply per network namespace. This unblocks some use-cases where users would like to e.g. not do bridge filtering for bridges in a specific network namespace while doing so for bridges located in another network namespace. The netfilter rules are afaict already per network namespace so it should be safe for users to specify whether bridge devices inside a network namespace are supposed to go through iptables et al. or not. Also, this can already be done per-bridge by setting an option for each individual bridge via Netlink. It should also be possible to do this for all bridges in a network namespace via sysctls. I've pushed a small series of patches upstream. Please backport them to our LTS kernels. :) ** Affects: linux (Ubuntu) Importance: Undecided Status: Confirmed -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1836910 Title: br_netfilter: namespace sysctl operations Status in linux package in Ubuntu: Confirmed Bug description: Currently, the /proc/sys/net/bridge folder is only created in the initial network namespace. This patch ensures that the /proc/sys/net/bridge folder is available in each network namespace if the module is loaded and disappears from all network namespaces when the module is unloaded. In doing so the patch makes the sysctls: bridge-nf-call-arptables bridge-nf-call-ip6tables bridge-nf-call-iptables bridge-nf-filter-pppoe-tagged bridge-nf-filter-vlan-tagged bridge-nf-pass-vlan-input-dev apply per network namespace. This unblocks some use-cases where users would like to e.g. not do bridge filtering for bridges in a specific network namespace while doing so for bridges located in another network namespace. The netfilter rules are afaict already per network namespace so it should be safe for users to specify whether bridge devices inside a network namespace are supposed to go through iptables et al. or not. Also, this can already be done per-bridge by setting an option for each individual bridge via Netlink. It should also be possible to do this for all bridges in a network namespace via sysctls. I've pushed a small series of patches upstream. Please backport them to our LTS kernels. :) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1836910/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1828227] Re: shiftfs: allow changing ro/rw for subvolumes
** Changed in: linux (Ubuntu) Status: Expired => Fix Released ** Changed in: linux (Ubuntu) Assignee: (unassigned) => Christian Brauner (cbrauner) -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1828227 Title: shiftfs: allow changing ro/rw for subvolumes Status in linux package in Ubuntu: Fix Released Bug description: Unprivileged users can already toggle whether a subvolume will be ro or rw. Not having this working with shiftfs regresses various use-cases. Issues have already been seen by Stéphane Graber (Cced here). To enable this with shiftfs we need to whitelist BTRFS_IOC_FS_INFO, BTRFS_IOC_SUBVOL_GETFLAGS, BTRFS_IOC_SUBVOL_SETFLAGS. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1828227/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1832316] Re: shiftfs: allow changing ro/rw for subvolumes
Sent patch: https://lists.ubuntu.com/archives/kernel-team/2019-June/101305.html -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1832316 Title: shiftfs: allow changing ro/rw for subvolumes Status in linux package in Ubuntu: In Progress Bug description: SRU Justification Impact: Stéphane reported regression for btrfs workloads employing shiftfs. Unprivileged users can already toggle whether a subvolume will be ro or rw. This is broken on current shiftfs as we haven't whitelisted these ioctls(). Fix: To enable this with shiftfs we need to whitelist BTRFS_IOC_FS_INFO, BTRFS_IOC_SUBVOL_GETFLAGS, BTRFS_IOC_SUBVOL_SETFLAGS. All of them should be safe for unprivileged users. Regression Potential: Limited to shiftfs. Test Case: Tested with LXD running shiftfs on top of btrfs and verified btrfs subvolumes can be made ro or rw. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1832316/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1832316] Re: shiftfs: allow changing ro/rw for subvolumes
** Changed in: linux (Ubuntu) Status: Incomplete => Confirmed ** Changed in: linux (Ubuntu) Status: Confirmed => In Progress ** Changed in: linux (Ubuntu) Assignee: (unassigned) => Christian Brauner (cbrauner) -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1832316 Title: shiftfs: allow changing ro/rw for subvolumes Status in linux package in Ubuntu: In Progress Bug description: SRU Justification Impact: Stéphane reported regression for btrfs workloads employing shiftfs. Unprivileged users can already toggle whether a subvolume will be ro or rw. This is broken on current shiftfs as we haven't whitelisted these ioctls(). Fix: To enable this with shiftfs we need to whitelist BTRFS_IOC_FS_INFO, BTRFS_IOC_SUBVOL_GETFLAGS, BTRFS_IOC_SUBVOL_SETFLAGS. All of them should be safe for unprivileged users. Regression Potential: Limited to shiftfs. Test Case: Tested with LXD running shiftfs on top of btrfs and verified btrfs subvolumes can be made ro or rw. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1832316/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1832316] [NEW] shiftfs: allow changing ro/rw for subvolumes
Public bug reported: SRU Justification Impact: Stéphane reported regression for btrfs workloads employing shiftfs. Unprivileged users can already toggle whether a subvolume will be ro or rw. This is broken on current shiftfs as we haven't whitelisted these ioctls(). Fix: To enable this with shiftfs we need to whitelist BTRFS_IOC_FS_INFO, BTRFS_IOC_SUBVOL_GETFLAGS, BTRFS_IOC_SUBVOL_SETFLAGS. All of them should be safe for unprivileged users. Regression Potential: Limited to shiftfs. Test Case: Tested with LXD running shiftfs on top of btrfs and verified btrfs subvolumes can be made ro or rw. ** Affects: linux (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1832316 Title: shiftfs: allow changing ro/rw for subvolumes Status in linux package in Ubuntu: New Bug description: SRU Justification Impact: Stéphane reported regression for btrfs workloads employing shiftfs. Unprivileged users can already toggle whether a subvolume will be ro or rw. This is broken on current shiftfs as we haven't whitelisted these ioctls(). Fix: To enable this with shiftfs we need to whitelist BTRFS_IOC_FS_INFO, BTRFS_IOC_SUBVOL_GETFLAGS, BTRFS_IOC_SUBVOL_SETFLAGS. All of them should be safe for unprivileged users. Regression Potential: Limited to shiftfs. Test Case: Tested with LXD running shiftfs on top of btrfs and verified btrfs subvolumes can be made ro or rw. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1832316/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1832316] Re: shiftfs: allow changing ro/rw for subvolumes
See https://git.launchpad.net/~cbrauner/ubuntu/+source/linux/+git/disco/log/?h=2019-05-07/shiftfs_btrfs_ioctls -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1832316 Title: shiftfs: allow changing ro/rw for subvolumes Status in linux package in Ubuntu: New Bug description: SRU Justification Impact: Stéphane reported regression for btrfs workloads employing shiftfs. Unprivileged users can already toggle whether a subvolume will be ro or rw. This is broken on current shiftfs as we haven't whitelisted these ioctls(). Fix: To enable this with shiftfs we need to whitelist BTRFS_IOC_FS_INFO, BTRFS_IOC_SUBVOL_GETFLAGS, BTRFS_IOC_SUBVOL_SETFLAGS. All of them should be safe for unprivileged users. Regression Potential: Limited to shiftfs. Test Case: Tested with LXD running shiftfs on top of btrfs and verified btrfs subvolumes can be made ro or rw. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1832316/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1828227] [NEW] shiftfs: allow changing ro/rw for subvolumes
Public bug reported: Unprivileged users can already toggle whether a subvolume will be ro or rw. Not having this working with shiftfs regresses various use-cases. Issues have already been seen by Stéphane Graber (Cced here). To enable this with shiftfs we need to whitelist BTRFS_IOC_FS_INFO, BTRFS_IOC_SUBVOL_GETFLAGS, BTRFS_IOC_SUBVOL_SETFLAGS. ** Affects: linux (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1828227 Title: shiftfs: allow changing ro/rw for subvolumes Status in linux package in Ubuntu: New Bug description: Unprivileged users can already toggle whether a subvolume will be ro or rw. Not having this working with shiftfs regresses various use-cases. Issues have already been seen by Stéphane Graber (Cced here). To enable this with shiftfs we need to whitelist BTRFS_IOC_FS_INFO, BTRFS_IOC_SUBVOL_GETFLAGS, BTRFS_IOC_SUBVOL_SETFLAGS. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1828227/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1827122] Re: shiftfs: lock security sensitive superblock flags
** Patch added: "0001-UBUNTU-SAUCE-shiftfs-lock-down-certain-superblock-fl.patch" https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1827122/+attachment/5260369/+files/0001-UBUNTU-SAUCE-shiftfs-lock-down-certain-superblock-fl.patch -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1827122 Title: shiftfs: lock security sensitive superblock flags Status in linux package in Ubuntu: In Progress Bug description: Felix Abecassis from Nvidia recently reported the following bug: "I recently upgraded to Ubuntu 19.04, and decided to experiment with shiftfs and unprivileged overlay. My goal was to have root (in my case, the docker daemon) download overlay layers and then have multiple users leveraging shiftfs + unprivileged overlay to assemble the rootfs without copying and chowning. For obvious security reasons, I want root to expose these layers as read-only, any change will be to the user-owned "upper" filesystem. Here's what I'm currently doing: # Exposing the root-owned docker layers, the "ro" option seems to have no impact on later userns mounts. sudo mount -t shiftfs -o mark,ro /var/lib/docker/overlay2 /mnt # Creating a userns as uid 1000, then mounting the shiftfs. unshare -U -m -r cd $(mktemp -d) mkdir shiftfs upper work merged # I can pass "ro" to the mount to get the behavior I want. mount -t shiftfs -o ro /mnt shiftfs mount -t overlay overlay -o 'lowerdir=shiftfs/c34c048514dcab5fc1bddf6d99681645786021e4a5b239972ec688386852a666/diff:[...],upperdir=upper,workdir=work' merged This works fine (excluding the xattrs issue with unprivileged overlay), but I can't rely on users to pass the "ro" option to their mounts. Without it, any user would be able to write to /var/lib/docker/overlay2 through the shiftfs mountpoint. I couldn't find a way to enforce do that, is there one? Is it possible to have one? I quickly attempted to have root do the shiftfs mounts for the users, but it seems the shift is always for the root of the current userns, and can't be done for another user." To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1827122/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1827122] [NEW] shiftfs: lock security sensitive superblock flags
Public bug reported:
Felix Abecassis from Nvidia recently reported the following bug:
"I recently upgraded to Ubuntu 19.04, and decided to experiment with shiftfs
and unprivileged overlay.
My goal was to have root (in my case, the docker daemon) download overlay
layers and then have multiple users leveraging shiftfs + unprivileged overlay
to assemble the rootfs without copying and chowning.
For obvious security reasons, I want root to expose these layers as read-only,
any change will be to the user-owned "upper" filesystem.
Here's what I'm currently doing:
# Exposing the root-owned docker layers, the "ro" option seems to have no
impact on later userns mounts.
sudo mount -t shiftfs -o mark,ro /var/lib/docker/overlay2 /mnt
# Creating a userns as uid 1000, then mounting the shiftfs.
unshare -U -m -r
cd $(mktemp -d)
mkdir shiftfs upper work merged
# I can pass "ro" to the mount to get the behavior I want.
mount -t shiftfs -o ro /mnt shiftfs
mount -t overlay overlay -o
'lowerdir=shiftfs/c34c048514dcab5fc1bddf6d99681645786021e4a5b239972ec688386852a666/diff:[...],upperdir=upper,workdir=work'
merged
This works fine (excluding the xattrs issue with unprivileged overlay),
but I can't rely on users to pass the "ro" option to their mounts.
Without it, any user would be able to write to /var/lib/docker/overlay2
through the shiftfs mountpoint.
I couldn't find a way to enforce do that, is there one? Is it possible to have
one?
I quickly attempted to have root do the shiftfs mounts for the users, but it
seems the shift is always for the root of the current userns, and can't be done
for another user."
** Affects: linux (Ubuntu)
Importance: Undecided
Assignee: Christian Brauner (cbrauner)
Status: In Progress
** Changed in: linux (Ubuntu)
Status: New => Confirmed
** Changed in: linux (Ubuntu)
Assignee: (unassigned) => Christian Brauner (cbrauner)
** Changed in: linux (Ubuntu)
Status: Confirmed => In Progress
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1827122
Title:
shiftfs: lock security sensitive superblock flags
Status in linux package in Ubuntu:
In Progress
Bug description:
Felix Abecassis from Nvidia recently reported the following bug:
"I recently upgraded to Ubuntu 19.04, and decided to experiment with shiftfs
and unprivileged overlay.
My goal was to have root (in my case, the docker daemon) download overlay
layers and then have multiple users leveraging shiftfs + unprivileged overlay
to assemble the rootfs without copying and chowning.
For obvious security reasons, I want root to expose these layers as
read-only, any change will be to the user-owned "upper" filesystem.
Here's what I'm currently doing:
# Exposing the root-owned docker layers, the "ro" option seems to have no
impact on later userns mounts.
sudo mount -t shiftfs -o mark,ro /var/lib/docker/overlay2 /mnt
# Creating a userns as uid 1000, then mounting the shiftfs.
unshare -U -m -r
cd $(mktemp -d)
mkdir shiftfs upper work merged
# I can pass "ro" to the mount to get the behavior I want.
mount -t shiftfs -o ro /mnt shiftfs
mount -t overlay overlay -o
'lowerdir=shiftfs/c34c048514dcab5fc1bddf6d99681645786021e4a5b239972ec688386852a666/diff:[...],upperdir=upper,workdir=work'
merged
This works fine (excluding the xattrs issue with unprivileged
overlay), but I can't rely on users to pass the "ro" option to their
mounts. Without it, any user would be able to write to
/var/lib/docker/overlay2 through the shiftfs mountpoint.
I couldn't find a way to enforce do that, is there one? Is it possible to
have one?
I quickly attempted to have root do the shiftfs mounts for the users, but it
seems the shift is always for the root of the current userns, and can't be done
for another user."
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1827122/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1824812] Re: apparmor does not start in Disco LXD containers
Okay, I have a fix for the shiftfs side I think. Attached here. ** Patch added: "UBUNTU: SAUCE: shiftfs: use correct llseek method for" https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1824812/+attachment/5256074/+files/0001-UBUNTU-SAUCE-shiftfs-use-correct-llseek-method-for-d.patch -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1824812 Title: apparmor does not start in Disco LXD containers Status in AppArmor: Triaged Status in apparmor package in Ubuntu: In Progress Status in libvirt package in Ubuntu: Invalid Status in linux package in Ubuntu: Confirmed Bug description: In LXD apparmor now skips starting. Steps to reproduce: 1. start LXD container $ lxc launch ubuntu-daily:d d-testapparmor (disco to trigger the issue, cosmic as reference) 2. check the default profiles loaded $ aa-status => This will in cosmic and up to recently disco list plenty of profiles active even in the default install. Cosmic: 25 profiles are loaded. 25 profiles are in enforce mode. Disco: 15 profiles are loaded. 15 profiles are in enforce mode. All those 15 remaining are from snaps. The service of apparmor.service actually states that it refuses to start. $ systemctl status apparmor ... Apr 15 13:56:12 testkvm-disco-to apparmor.systemd[101]: Not starting AppArmor in container I can get those profiles (the default installed ones) loaded, for example: $ sudo apparmor_parser -r /etc/apparmor.d/sbin.dhclient makes it appear 22 profiles are in enforce mode. /sbin/dhclient I was wondering as in my case I found my guest with no (=0) profiles loaded. But as shown above after "apparmor_parser -r" and package install profiles seemed fine. Then the puzzle was solved, on package install they will call apparmor_parser via the dh_apparmor snippet and it is fine. To fully disable all of them: $ lxc stop $ lxc start $ lxc exec d-testapparmor aa-status apparmor module is loaded. 0 profiles are loaded. 0 profiles are in enforce mode. 0 profiles are in complain mode. 0 processes have profiles defined. 0 processes are in enforce mode. 0 processes are in complain mode. 0 processes are unconfined but have a profile defined. That would match the service doing an early exit as shown in systemctl status output above. The package install or manual load works, but none are loaded by the service automatically e.g. on container restart. --- --- --- This bug started as: Migrations to Disco trigger "Unable to find security driver for model apparmor" This most likely is related to my KVM-in-LXD setup but it worked fine for years and I'd like to sort out what broke. I have migrated to Disco's qemu 3.1 already which makes me doubts generic issues in qemu 3.1 in general. The virt tests that run cross release work fine starting from X/B/C but all those chains fail at mirgating to Disco now with: $ lxc exec testkvm-cosmic-from -- virsh migrate --unsafe --live kvmguest-bionic-normal qemu+ssh://10.21.151.207/system error: unsupported configuration: Unable to find security driver for model apparmor I need to analyze what changed To manage notifications about this bug go to: https://bugs.launchpad.net/apparmor/+bug/1824812/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1824735] Re: shiftfs: use after free when checking mount options
** Changed in: linux (Ubuntu) Status: In Progress => Fix Committed -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1824735 Title: shiftfs: use after free when checking mount options Status in linux package in Ubuntu: Fix Committed Bug description: SRU Justification Impact: We currently keep a reference to the shiftfs mark mount's shiftfs_super_info which was stashed in the superblock of the mark mount. The problem is that we only take a reference to the mount of the underlay, i.e. the filesystem that is *under* the shiftfs mark mount. This means when someone performs a shiftfs mark mount, then a shiftfs overlay mount and then immediately unmounts the shiftfs mark mount we muck with invalid memory since shiftfs_put_super might have already been called freeing that memory. Fix: Copy up the passthrough mount settings of the mark mount point to the shiftfs overlay. An alternative solution would be to start reference counting. But this is overkill. We only care about the passthrough mount option of the mark mount. And we only need it to verify that on remount the new passthrough options of the shiftfs overlay are a subset of the mark mount's passthrough options. In other scenarios we don't care. So copying up is good enough and also only needs to happen once on mount, i.e. when a new superblock is created and the .fill_super method is called. Regression Potential: Limited to shiftfs, matches the behavior of other stacked filesystems, and has been tested (see below). Test Case: Built Ubuntu Disco Kernel with patch applied from source, installed it, ran LXD and verified that passthrough mount option now works correctly. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1824735/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1824735] Re: shiftfs: use after free when checking mount options
** Description changed: SRU Justification Impact: We currently keep a reference to the shiftfs mark mount's shiftfs_super_info which was stashed in the superblock of the mark mount. The problem is that we only take a reference to the mount of the underlay, i.e. the filesystem that is *under* the shiftfs mark mount. This means when someone performs a shiftfs mark mount, then a shiftfs overlay mount and then immediately unmounts the shiftfs mark mount we muck with invalid memory since shiftfs_put_super might have already been called freeing that memory. Fix: Copy up the passthrough mount settings of the mark mount point to the shiftfs overlay. An alternative solution would be to start reference counting. But this is overkill. We only care about the passthrough mount option of the mark mount. And we only need it to verify that on remount the new passthrough options of the shiftfs overlay are a subset of the mark mount's passthrough options. In other scenarios we don't care. So copying up is good enough and also only needs to happen once on mount, i.e. when a new superblock is created and the .fill_super method is called. Regression Potential: Limited to shiftfs, matches the behavior of other stacked filesystems, and has been tested (see below). + + Test Case: Built Ubuntu Disco Kernel with patch applied from source, + installed it, ran LXD and verified that passthrough mount option now + works correctly. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1824735 Title: shiftfs: use after free when checking mount options Status in linux package in Ubuntu: In Progress Bug description: SRU Justification Impact: We currently keep a reference to the shiftfs mark mount's shiftfs_super_info which was stashed in the superblock of the mark mount. The problem is that we only take a reference to the mount of the underlay, i.e. the filesystem that is *under* the shiftfs mark mount. This means when someone performs a shiftfs mark mount, then a shiftfs overlay mount and then immediately unmounts the shiftfs mark mount we muck with invalid memory since shiftfs_put_super might have already been called freeing that memory. Fix: Copy up the passthrough mount settings of the mark mount point to the shiftfs overlay. An alternative solution would be to start reference counting. But this is overkill. We only care about the passthrough mount option of the mark mount. And we only need it to verify that on remount the new passthrough options of the shiftfs overlay are a subset of the mark mount's passthrough options. In other scenarios we don't care. So copying up is good enough and also only needs to happen once on mount, i.e. when a new superblock is created and the .fill_super method is called. Regression Potential: Limited to shiftfs, matches the behavior of other stacked filesystems, and has been tested (see below). Test Case: Built Ubuntu Disco Kernel with patch applied from source, installed it, ran LXD and verified that passthrough mount option now works correctly. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1824735/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1824735] Re: shiftfs: use after free when checking mount options
** Description changed: SRU Justification Impact: We currently keep a reference to the shiftfs mark mount's shiftfs_super_info which was stashed in the superblock of the mark mount. The problem is that we only take a reference to the mount of the underlay, i.e. the filesystem that is *under* the shiftfs mark mount. This means when someone performs a shiftfs mark mount, then a shiftfs overlay mount and then immediately unmounts the shiftfs mark mount we muck with invalid memory since shiftfs_put_super might have already been called freeing that memory. Fix: Copy up the passthrough mount settings of the mark mount point to the shiftfs overlay. An alternative solution would be to start reference counting. But this is overkill. We only care about the passthrough mount option of the mark mount. And we only need it to verify that on remount the new passthrough options of the shiftfs overlay are a subset of the mark mount's passthrough options. In other scenarios we don't care. So copying up is good enough and also only needs to happen once on mount, i.e. when a new superblock is created and the .fill_super method is called. Regression Potential: Limited to shiftfs, matches the behavior of other stacked filesystems, and has been tested (see below). - - Test Case: Tested in the lxd CI environment where the bug was originally - discovered. No regressions were seen, and the BUG statement was not hit. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1824735 Title: shiftfs: use after free when checking mount options Status in linux package in Ubuntu: In Progress Bug description: SRU Justification Impact: We currently keep a reference to the shiftfs mark mount's shiftfs_super_info which was stashed in the superblock of the mark mount. The problem is that we only take a reference to the mount of the underlay, i.e. the filesystem that is *under* the shiftfs mark mount. This means when someone performs a shiftfs mark mount, then a shiftfs overlay mount and then immediately unmounts the shiftfs mark mount we muck with invalid memory since shiftfs_put_super might have already been called freeing that memory. Fix: Copy up the passthrough mount settings of the mark mount point to the shiftfs overlay. An alternative solution would be to start reference counting. But this is overkill. We only care about the passthrough mount option of the mark mount. And we only need it to verify that on remount the new passthrough options of the shiftfs overlay are a subset of the mark mount's passthrough options. In other scenarios we don't care. So copying up is good enough and also only needs to happen once on mount, i.e. when a new superblock is created and the .fill_super method is called. Regression Potential: Limited to shiftfs, matches the behavior of other stacked filesystems, and has been tested (see below). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1824735/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
