** Description changed: + SRU Justification + + Impact: The pid namespace support in fuse refuses requests from any + process whose pid does not map into the pid namespace of the fuse + userspace process. This has caused a regression for at least one user. + + Fix: Permit requests from processes whose pid does not map. Fill in the + pid value in the fuse request with 0. + + Regression potential: A fuse filesystem not prepared to handle a pid of + 0 in fuse requests might have problems. However such a filesystem would + also receive pid values which aren't valid for its namespace when used + across pid namespaces in this manner with upstream kernels, so this + isn't a major concern. + + --- + The discussion starts at http://thread.gmane.org/gmane.linux.kernel.cgroups/15960/focus=2269876 Commit in the tree is: commit a166e6726c6e12e28ac8489ff4e2faff7065a856 Author: Seth Forshee <seth.fors...@canonical.com> Date: Wed Jul 2 16:29:19 2014 -0500 - UBUNTU: SAUCE: fuse: Add support for pid namespaces + UBUNTU: SAUCE: fuse: Add support for pid namespaces Description of the issue(copied from my report of lkml): This patch caused a regression in our major container use case with FUSE in Ubuntu 16.04, as patch was checked in as Ubuntu Sauce in Ubuntu 4.4.0-6.21 kernel. The use case is: 1. Create a Docker container. 2. Inside the container, start the FUSE backend, and mounted fs. 3. Following step 2 in the container, create a loopback device to map a file in the mounted fuse to create a block device, which will be available to the whole system. It works well before this commit. The use case is broken because no matter which namespace losetup runs, the real request from loopback device seems always come from init ns, thus it will be in different ns running fuse backend. So the request will got denied, because the ns running fuse won't able to see the things from higher level(level 0 in fact) pid namespace. - --- + --- ApportVersion: 2.14.1-0ubuntu3.21 Architecture: amd64 DistroRelease: Ubuntu 14.04 Package: linux (not installed) ProcEnviron: - TERM=xterm-256color - PATH=(custom, no user) - LANG=en_US.UTF-8 - SHELL=/bin/bash + TERM=xterm-256color + PATH=(custom, no user) + LANG=en_US.UTF-8 + SHELL=/bin/bash ProcVersionSignature: - + Tags: trusty Uname: Linux 4.4.6 x86_64 UnreportableReason: The running kernel is not an Ubuntu kernel UpgradeStatus: No upgrade log present (probably fresh install) UserGroups: - + _MarkForUpload: True
-- 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/1605344 Title: Regression caused by `fuse: Add support for pid namespaces` in 4.4.0-6.21 Status in linux package in Ubuntu: Triaged Status in linux source package in Xenial: In Progress Bug description: SRU Justification Impact: The pid namespace support in fuse refuses requests from any process whose pid does not map into the pid namespace of the fuse userspace process. This has caused a regression for at least one user. Fix: Permit requests from processes whose pid does not map. Fill in the pid value in the fuse request with 0. Regression potential: A fuse filesystem not prepared to handle a pid of 0 in fuse requests might have problems. However such a filesystem would also receive pid values which aren't valid for its namespace when used across pid namespaces in this manner with upstream kernels, so this isn't a major concern. --- The discussion starts at http://thread.gmane.org/gmane.linux.kernel.cgroups/15960/focus=2269876 Commit in the tree is: commit a166e6726c6e12e28ac8489ff4e2faff7065a856 Author: Seth Forshee <seth.fors...@canonical.com> Date: Wed Jul 2 16:29:19 2014 -0500 UBUNTU: SAUCE: fuse: Add support for pid namespaces Description of the issue(copied from my report of lkml): This patch caused a regression in our major container use case with FUSE in Ubuntu 16.04, as patch was checked in as Ubuntu Sauce in Ubuntu 4.4.0-6.21 kernel. The use case is: 1. Create a Docker container. 2. Inside the container, start the FUSE backend, and mounted fs. 3. Following step 2 in the container, create a loopback device to map a file in the mounted fuse to create a block device, which will be available to the whole system. It works well before this commit. The use case is broken because no matter which namespace losetup runs, the real request from loopback device seems always come from init ns, thus it will be in different ns running fuse backend. So the request will got denied, because the ns running fuse won't able to see the things from higher level(level 0 in fact) pid namespace. --- ApportVersion: 2.14.1-0ubuntu3.21 Architecture: amd64 DistroRelease: Ubuntu 14.04 Package: linux (not installed) ProcEnviron: TERM=xterm-256color PATH=(custom, no user) LANG=en_US.UTF-8 SHELL=/bin/bash ProcVersionSignature: Tags: trusty Uname: Linux 4.4.6 x86_64 UnreportableReason: The running kernel is not an Ubuntu kernel UpgradeStatus: No upgrade log present (probably fresh install) UserGroups: _MarkForUpload: True To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1605344/+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
