group.of.nepali.translators team mailing list archive

[Po-Hsu Lin <po-hsu.lin@xxxxxxxxxxxxx>]

** Changed in: linux (Ubuntu)
       Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
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:
  Fix Released
Status in linux source package in Xenial:
  Fix Released

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.forshee@xxxxxxxxxxxxx>
  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