I had a slight misunderstanding when I looked at the code previously. The copy up is of the parent directory, which makes sense because it needs to modify one of the dirents in that directory. Which by extension means that every ancestor of the dirent being unlinked needs to be copied up.
So the problem is not the owner of the inode which is the target of the unlink, but those of the ancestor directories. The tmpfs mount in the user ns cannot contain uids not mapped into the user ns, which is why the copy up fails. Since the directory will hang around after the unlink finishes, we don't want to change its ownership, but a directory with that ownership cannot exist in the tmpfs mount. The problem may indeed be intractable then. Is this breaking some real- world use case? Note that even if we could do the copy up, I'm not sure that we should. Generally speaking we don't want overlayfs to allow the user to create objects in the upperdir that the mounter of the overlayfs filesystem could not have created by other means. -- 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/1617388 Title: When using overlayfs with kernel 4.4, some files cannot be deleted. Status in linux package in Ubuntu: Triaged Bug description: #!/bin/bash # --------------------------------------------------------------------- # This script exhibits a bug in overlayfs in kernel 4.4. # The bug is not present in kernel 4.2. # The bug can be reproduced in an x86_64 virtual-machine; # 32-bit has not been tested. # # With kernel 4.2, the script output ends with: # "script completed without encountering a kernel bug" # # With kernel 4.4, the script output ends with: # "rm: cannot remove ‘mnt_ovl/sub/sub.txt’: # Value too large for defined data type" # # The script depends upon lxc-usernsexec (part of the lxc1 package) to # create a user-namespace. # # The script should be run as a normal user (not root), in a directory where # the user has write-permission: # ./script # -------------------------------------------------------------------- cleanup() { [[ -d "$storedir" ]] || exit 1 cd "$storedir" || exit 1 [[ -d "$tmpdir" ]] || exit 1 lxc-usernsexec -m b:0:1000:1 -m b:100000:100000:1 -- rm -rf "$tmpdir" } trap cleanup EXIT set -e storedir="$(pwd)" # create tmpdir tmpdir="$(mktemp -d --tmpdir=.)" cd "$tmpdir" # create lowerdir for overlay mkdir -p lower/sub touch lower/lower.txt lower/sub/sub.txt cd .. chmod -R a+rwX "$tmpdir" # run a script in a user namepace lxc-usernsexec -m b:0:100000:65534 -- bash << EOF set -e cd "$tmpdir" # create tmpfs mkdir mnt_tmpfs mount -t tmpfs tmpfs mnt_tmpfs # create upperdir and workdir for overlay mkdir mnt_tmpfs/{upper,work} # mount overlay mkdir mnt_ovl mount -t overlay \ -o lowerdir=lower,upperdir=mnt_tmpfs/upper,workdir=mnt_tmpfs/work \ overlay mnt_ovl echo 'overlay directory listing' ls -RF mnt_ovl echo '' set -x rm mnt_ovl/lower.txt # always succeeds rm mnt_ovl/sub/sub.txt # fails with kernel 4.4+ set +x echo 'script completed without encountering a kernel bug' EOF To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1617388/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
