bug#32796: please consider using renameat2 from glibc if available

[Johannes Schauer]

Hi,

Quoting Paul Eggert (2018-10-07 02:54:09)
> Andreas Henriksson wrote:
> > wouldn't a simple patch like the attached one do the trick?
> Most likely yes, but I'd like it tested before installing. This is because 
> the 
> patch shouldn't affect behavior on any platform, and it's better to 
> sanity-check 
> a clerical patch like this (by actually using it) rather than hoping that a 
> typo 
> didn't inadvertently introduce a bug.

I just did a naive test on Debian unstable.

First, I built glibc because Debian still ships 2.27 but renameat2 is only in
2.28. Then, I applied Andreas' patch on coreutils 8.30. The only changes to
Andreas' patch I had to do were to rename the renameat2 function from coreutils
to renameatu as it's already done in the coreutils git. Otherwise, the code
from coreutils 8.30 would perform an infinite recursion. Then, I then rebuilt
fakechroot with the new glibc and a patch that adds support for glibc's
renameat2 function. Lastly, I created a Debian chroot with the new glibc,
coreutils and fakechroot and then, within a nested chroot tried to execute:

    $ mv /etc/fstab /etc/blub

To prove that this now works I attached the strace output from before and after
I patched everything. The file fakechroot.old shows that renameat2 tries to
rename the real /etc/fstab for which it doesn't have permission. The file
fakechroot.new shows that the path to the /etc/fstab inside the chroot is
properly translated and thus does not anymore yield an EACCESS.

Which other tests should I perform?

Thanks!

cheers, josch

fakechroot.old
Description: Text document

fakechroot.new
Description: Text document

signature.asc
Description: signature