| 2016-07-21 17:53:25 |
Sheng Yang |
bug |
|
|
added bug |
| 2016-07-21 18:00:08 |
Brad Figg |
linux (Ubuntu): status |
New |
Incomplete |
|
| 2016-07-21 18:20:06 |
Sheng Yang |
tags |
|
apport-collected trusty |
|
| 2016-07-21 18:20:08 |
Sheng Yang |
description |
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.forshee@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. |
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.forshee@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 |
|
| 2016-07-21 18:23:47 |
Sheng Yang |
tags |
apport-collected trusty |
xenial |
|
| 2016-07-21 18:32:03 |
Joseph Salisbury |
linux (Ubuntu): importance |
Undecided |
Medium |
|
| 2016-07-21 18:32:08 |
Joseph Salisbury |
linux (Ubuntu): status |
Incomplete |
Triaged |
|
| 2016-07-21 18:35:50 |
Seth Forshee |
nominated for series |
|
Ubuntu Xenial |
|
| 2016-07-21 18:35:50 |
Seth Forshee |
bug task added |
|
linux (Ubuntu Xenial) |
|
| 2016-07-21 18:35:59 |
Seth Forshee |
linux (Ubuntu Xenial): status |
New |
In Progress |
|
| 2016-07-21 18:36:03 |
Seth Forshee |
linux (Ubuntu Xenial): importance |
Undecided |
High |
|
| 2016-07-21 18:36:05 |
Seth Forshee |
linux (Ubuntu Xenial): assignee |
|
Seth Forshee (sforshee) |
|
| 2016-07-28 13:58:37 |
Seth Forshee |
attachment added |
|
0001-UBUNTU-SAUCE-namespace-fuse-Permit-requests-from-oth.patch https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1605344/+attachment/4708792/+files/0001-UBUNTU-SAUCE-namespace-fuse-Permit-requests-from-oth.patch |
|
| 2016-07-28 14:03:41 |
Seth Forshee |
description |
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.forshee@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 |
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.forshee@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 |
|
| 2016-07-28 16:27:35 |
Ubuntu Foundations Team Bug Bot |
tags |
xenial |
patch xenial |
|
| 2016-07-28 16:27:36 |
Ubuntu Foundations Team Bug Bot |
bug |
|
|
added subscriber Joseph Salisbury |
| 2016-07-28 19:19:49 |
Kamal Mostafa |
linux (Ubuntu Xenial): status |
In Progress |
Fix Committed |
|
| 2016-08-01 19:34:54 |
Andy Whitcroft |
linux (Ubuntu): status |
Triaged |
Fix Committed |
|
| 2016-08-16 14:08:18 |
Stefan Bader |
tags |
patch xenial |
patch verification-needed-xenial xenial |
|
| 2016-08-16 22:20:41 |
Sheng Yang |
tags |
patch verification-needed-xenial xenial |
patch verification-done-xenial xenial |
|
| 2016-08-29 14:10:47 |
Launchpad Janitor |
linux (Ubuntu Xenial): status |
Fix Committed |
Fix Released |
|
| 2016-08-29 14:10:47 |
Launchpad Janitor |
cve linked |
|
2016-5244 |
|
| 2016-08-29 14:10:47 |
Launchpad Janitor |
cve linked |
|
2016-5400 |
|
| 2016-08-29 14:10:47 |
Launchpad Janitor |
cve linked |
|
2016-5696 |
|
| 2016-08-29 14:10:47 |
Launchpad Janitor |
cve linked |
|
2016-5728 |
|
| 2019-10-03 08:07:19 |
Po-Hsu Lin |
linux (Ubuntu): status |
Fix Committed |
Fix Released |
|
