I'm pretty sure this is related to copy up. For some reason, when
unlinking a file in the lowerdir that isn't in the upperdir overlayfs
first copies up the file from the lowerdir, then replaces it with a
whiteout. There are a couple of problems with letting the user create
the inode in the upperdir though.

First, starting in xenial the tmpfs mount isn't going to allow any
inodes to be created in it that are not mapped into the user namespace.
This is generally a sensible policy as it presents users from inserting
inodes into the system owned by users over which they have no
privileges.

Second, even if the upperdir wasn't limited in this matter, it's not
really a good idea to let a user create inodes owned by another user
without having privileges towards that user. In this case it's under
kernel control and immediately replaced by a whiteout, so it probably
doesn't pose a problem in reality. But generally allowing copy up of
such an inode to a mount over which the user is privileged could be
problematic.

So I'm going to have to think about this as we need to proceed very
carefully. Ideally we can just avoid the copy up and write the whiteout
directly, but I assume there must be some reason the code doesn't
already work that way.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1617388

Title:
  When using overlayfs with kernel 4.4, some files cannot be deleted.

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

-- 
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to