after i ran into this problem, dgreid@ stepped up and posted some backports
https://chromium-review.googlesource.com/#/q/project:chromiumos/third_party/kernel+owner:dgreid

he did it for 3.14 & 3.18.  not sure he was going to go back further than that.

Alright, that's reasonable. Dylan, are we running ARC++ on anything lower than 3.14? Is that why you stopped at 3.14?

3.14 is the minimum version for ARC++.  That's as far back as we have been taking most of the namespacing fixes.  It won't hurt to fix it in 3.10, but we don't use user namespaces there so it might not be worth the backport.

Definitely lower priority for 3.10. I wonder if we're ever going to use user namespaces for other sandboxing on things that run on all Chromebooks.

Seems like a bite-sized bug to get started with. I'll do this.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/d6f20c4d0518b8c1456af5ef979529a2a10b8cae

commit d6f20c4d0518b8c1456af5ef979529a2a10b8cae
Author: Eric W. Biederman <ebiederm@xmission.com>
Date: Wed May 03 00:45:20 2017

BACKPORT: userns: Add a knob to disable setgroups on a per user namespace basis

- Expose the knob to user space through a proc file /proc/<pid>/setgroups

  A value of "deny" means the setgroups system call is disabled in the
  current processes user namespace and can not be enabled in the
  future in this user namespace.

  A value of "allow" means the segtoups system call is enabled.

- Descendant user namespaces inherit the value of setgroups from
  their parents.

- A proc file is used (instead of a sysctl) as sysctls currently do
  not allow checking the permissions at open time.

- Writing to the proc file is restricted to before the gid_map
  for the user namespace is set.

  This ensures that disabling setgroups at a user namespace
  level will never remove the ability to call setgroups
  from a process that already has that ability.

  A process may opt in to the setgroups disable for itself by
  creating, entering and configuring a user namespace or by calling
  setns on an existing user namespace with setgroups disabled.
  Processes without privileges already can not call setgroups so this
  is a noop.  Prodcess with privilege become processes without
  privilege when entering a user namespace and as with any other path
  to dropping privilege they would not have the ability to call
  setgroups.  So this remains within the bounds of what is possible
  without a knob to disable setgroups permanently in a user namespace.

dgreid - context conflicts only
jclinton - remove patch to nonexistant userns_may_setgroups feature

Cc: stable@vger.kernel.org
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
(cherry picked from commit 9cc46516ddf497ea16e8d7cb986ae03a0f6b92f8)
Signed-off-by: Dylan Reid <dgreid@chromium.org>

Change-Id: Ic291878fa6e95a2b36f43833752d6e102e30a5a9
Reviewed-on: https://chromium-review.googlesource.com/424990
Commit-Ready: Dylan Reid <dgreid@chromium.org>
Tested-by: Dylan Reid <dgreid@chromium.org>
Reviewed-by: Guenter Roeck <groeck@chromium.org>
Signed-off-by: Jason D. Clinton <jclinton@chromium.org>

BUG= chromium:671770 
TEST=Build and deploy kernel.
Change-Id: I47025b65f92de37fcb5fec8db1a1905171d89ba6
Reviewed-on: https://chromium-review.googlesource.com/488130
Commit-Ready: Jason Clinton <jclinton@chromium.org>
Tested-by: Jason Clinton <jclinton@chromium.org>
Reviewed-by: Guenter Roeck <groeck@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>

[modify] https://crrev.com/d6f20c4d0518b8c1456af5ef979529a2a10b8cae/kernel/user.c
[modify] https://crrev.com/d6f20c4d0518b8c1456af5ef979529a2a10b8cae/fs/proc/base.c
[modify] https://crrev.com/d6f20c4d0518b8c1456af5ef979529a2a10b8cae/kernel/user_namespace.c
[modify] https://crrev.com/d6f20c4d0518b8c1456af5ef979529a2a10b8cae/include/linux/user_namespace.h