← Back to team overview

kernel-packages team mailing list archive

Re: [Bug 1531747] Re: overlay: mkdir fails if directory exists in lowerdir in a user namespace


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

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

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.

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

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

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: