Regression caused by `fuse: Add support for pid namespaces` in 4.4.0-6.21
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
linux (Ubuntu) |
Fix Released
|
Medium
|
Unassigned | ||
Xenial |
Fix Released
|
High
|
Seth Forshee |
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://
Commit in the tree is:
commit a166e6726c6e12e
Author: Seth Forshee <email address hidden>
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-
PATH=(custom, no user)
LANG=en_US.UTF-8
SHELL=/bin/bash
ProcVersionSign
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
tags: | added: apport-collected trusty |
description: | updated |
tags: |
added: xenial removed: apport-collected trusty |
Changed in linux (Ubuntu): | |
importance: | Undecided → Medium |
status: | Incomplete → Triaged |
Changed in linux (Ubuntu Xenial): | |
status: | New → In Progress |
importance: | Undecided → High |
assignee: | nobody → Seth Forshee (sforshee) |
description: | updated |
tags: | added: patch |
Changed in linux (Ubuntu Xenial): | |
status: | In Progress → Fix Committed |
Changed in linux (Ubuntu): | |
status: | Triaged → Fix Committed |
Changed in linux (Ubuntu): | |
status: | Fix Committed → Fix Released |
This bug is missing log files that will aid in diagnosing the problem. From a terminal window please run:
apport-collect 1605344
and then change the status of the bug to 'Confirmed'.
If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.
This change has been made by an automated script, maintained by the Ubuntu Kernel Team.