kernel-packages team mailing list archive

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

On Tue, Jan 12, 2016 at 05:16:28PM -0000, Serge Hallyn wrote:
> I'm still looking, but it may be safe to say that all needed inode
> checks are already done before we call ovl_set_opaque() so that we
> can indeed just use prepare_kernel_cred(NULL) instead of prepare_cred().

I've been looking too, only at ovl_create_over_whiteout so far. Here's
my take, though I'm still not an overlayfs expert so I may have missed
something.

Obviously the vfs is going to validate permissions to do the requested
operation in the overlayfs superblock. This will result in
ovl_permission getting called, which (for any write operation) is going
to validate that the caller has the necessary permissions towards the
relevant inode in uppderdir. That's good.

So by the time we raise the caps and call ovl_create_over_whiteout we
know that the user is allowed to do the operation, and
ovl_create_or_link is only changing upperdir in the ways needed to
satisfy this operation. Thus having the kernel assume full-on
CAP_SYS_ADMIN before calling ovl_create_or_link seems fine wrt to
upperdir.

But nothing is being checked wrt workdir before elevating the
capabilities. So maybe there are some checks at mount time to make sure
the user has permissions needed towards workdir? ovl_fill_super doesn't
appear to do so explicitly. However it does call ovl_workdir_create, and
this expects that $WORKDIR/work doesn't already exist (where $WORKDIR is
the string passed to mount via workdir=). If it does exist it tries to
remove it with either vfs_rmdir or vfs_unlink (both of which call
may_delete), then it tries to create $WORKDIR/work using vfs_mkdir
(which calls may_create). If either of these fails the mount is
read-only. This directory is what is used as the workdir for the mount,
so I think this effectively validates that the kernel can safely modify
the workdir in the same ways that it's modifying the upperdir.

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