kernel-packages team mailing list archive

[Seth Forshee <seth.forshee+lp@xxxxxxxxxxxxx>]

On Tue, Jan 12, 2016 at 04:56:24PM -0000, Serge Hallyn wrote:
> Quoting Seth Forshee (seth.forshee+lp@xxxxxxxxxxxxx):
> > I don't know why #2 is that much grosser than what's there now. It's
> 
> I didn't mean gross as in eeuw, I meant not fine-grained enough.
> 
> Because the capability will apply to inode permissions checks,
> and we only want it to be used for the check authorizing the
> writing of the trusted.overlay.opaque xattr.

That makes more sense. And that's the part that concerns me the most
too.

> > already only taking the cap for setting the xattr, and taking
> > CAP_SYS_ADMIN in init_user_ns seems to be what it's really wanting to do
> 
> Maybe - that's what I'm not sure about.  As you said earlier, in the
> upstream code only an admin can do the actual mount.  The fact that an
> unpriv user can create the mount may change assumptions about the
> underlying fs's.

Yeah, that's something I'm just not sure about. It seems like by
allowing the unprivileged user to mount in the first place we're
implicitly saying that it's okay to write these xattrs to the underlying
fs based on checks which happen at mount time. I don't know what checks
are actually done at mount time though; unless we've augmented them they
may be minimal based on the assumption that only CAP_SYS_ADMIN can
mount.

> > If we were to use ns_capable, which namespace do we use?
> 
> I don't know.  We're almost better off shipping a new version of
> vfs_xattr() which is only for use by kernel writers.

Maybe so.

-- 
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/1531747

Title:
  overlay: mkdir fails if directory exists in lowerdir in a user
  namespace

Status in linux package in Ubuntu:
  Triaged
Status in linux source package in Wily:
  Triaged
Status in linux source package in Xenial:
  Triaged

Bug description:
  If a directory exists in the lowerdir but not in the mounted
  overlay, then mkdir of the directory in the target dir results
  in a mysterious -EPERM.  I've seen this both in wily kernel
  (4.2.0-22-generic #27-Ubuntu) and in a hand-built xenial
  master-next (with unrelated patches added).

  =====================================================
  #!/bin/sh -ex
  dir=`mktemp -d`
  cleanup() {
   umount -l $dir/t
   rm -rf $dir
  }

  trap cleanup EXIT

  echo "dir is $dir"
  mkdir -p $dir/l $dir/u $dir/w $dir/t
  mkdir $dir/l/dev
  mount -t overlay -o lowerdir=$dir/l,upperdir=$dir/u,workdir=$dir/w o $dir/t
  stat $dir/t/dev
  rmdir $dir/t/dev
  mkdir $dir/t/dev
  echo $?
  echo "mkdir should have succeeded"
  =====================================================

  The above will work on the host, but fail in a user namespace, i.e
  in a regular lxd container.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1531747/+subscriptions