Ok, I see. At one point we had a special case to allow the overlay code to write trusted.* xattrs for creating whiteouts.
However that is gone. Therefore when overlayfs v1 (mount -t overlayfs) is mounted, root in a user namespace also is not able to rm a file which exists in the lower fs.
Some ways to fix this:
1. Add a special case in fs/xattr.c to allow the overlay code to create the trusted.overlay xattrs
2. In ovl_create_or_link(), target the override cred at init_user_ns. Since we don't do that, the capabilities we are adding do not grant "capable(CAP_SYS_ADMIN)", only ns_capable.
3. Find another way to do this without requiring the trusted.overlay xattr. It isn't needed for files so I don't know what the complications are, which require it to be done for directories.
Ok, I see. At one point we had a special case to allow the overlay code to write trusted.* xattrs for creating whiteouts.
However that is gone. Therefore when overlayfs v1 (mount -t overlayfs) is mounted, root in a user namespace also is not able to rm a file which exists in the lower fs.
Some ways to fix this:
1. Add a special case in fs/xattr.c to allow the overlay code to create the trusted.overlay xattrs or_link( ), target the override cred at init_user_ns. Since we don't do that, the capabilities we are adding do not grant "capable( CAP_SYS_ ADMIN)" , only ns_capable.
2. In ovl_create_
3. Find another way to do this without requiring the trusted.overlay xattr. It isn't needed for files so I don't know what the complications are, which require it to be done for directories.