kernel-packages team mailing list archive

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

On Thu, Jan 14, 2016 at 12:17:06AM -0000, Serge Hallyn wrote:
> Does it require the workdir to be empty?

Not empty. It wants to remove workdir/work if it exists and then create
workdir/work, see ovl_workdir_create. Removing workdir/work is done as
the user which is mounting, so nothing can be removed that the user
couldn't already remove. ovl_workdir_create is ultimately just using
vfs_rmdir if the directory exists, which is going to fail if
workdir/work isn't empty.

> I.e. is there a way (symlink, bind mount, something else) that a user
> could use a dir they own which has a child which they don't own?

I don't think so, since

1. lowerdir is not written to.
2. We've established that what's done with workdir won't make this
   possible.
3. When the vfs checks inode permissions for writing ovl_permission is
   called, which checks the permissions for the inode in upperdir for
   any write operation.

I've checked most of the places where overlay fs raises its credentials,
and I haven't found anything where it's doing anything with elevated
creds that isn't in line with the permission checks that would have
already been done. I'm still looking at ovl_rename2 though, which is
doing a lot more stuff with elevated creds than anywhere else.

Something I'm still not sure about is what would happen if you made a
symlink, bind mount, etc. in upperdir with the same name as an unrelated
file in lowerdir. This is worth checking out.

> It looks like no, since
> 
> root@w1:/tmp# mount -t overlay -o lowerdir=lower,upperdir=upper,workdir=workdir overlay /mnt
> root@w1:/tmp# ls /mnt
> cisco
> root@w1:/tmp# rmdir /mnt/cisco
> rmdir: failed to remove ‘/mnt/cisco’: Read-only file system
> root@w1:/tmp# mv /mnt/cisco /mnt/c2
> mv: cannot move ‘/mnt/cisco’ to ‘/mnt/c2’: Read-only file system
> 
> (here w1 is a unpriv container with /hostopt a bind mount of /opt on the
> host;  cisco a directory both in host's /opt and in /tmp/lowerdir)

I think I'm missing something here. I don't know why your mount is
read-only. But even if it wasn't, cisco is in lowerdir and thus should
never be modified or removed in any case. Removing it in /mnt should (I
think, still learning here) result in making a file in upperdir with the
whiteout xattr set.

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