GNU bug report logs - #32796
please consider using renameat2 from glibc if available

Previous Next

Package: coreutils;

Reported by: Johannes Schauer <josch <at> debian.org>

Date: Fri, 21 Sep 2018 15:22:02 UTC

Severity: normal

Tags: fixed

Done: Assaf Gordon <assafgordon <at> gmail.com>

Bug is archived. No further changes may be made.

Full log


Message #17 received at 32796 <at> debbugs.gnu.org (full text, mbox):

From: Johannes Schauer <josch <at> debian.org>
To: Andreas Henriksson <andreas <at> fatal.se>, Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 32796 <at> debbugs.gnu.org
Subject: Re: bug#32796: please consider using renameat2 from glibc if available
Date: Sun, 07 Oct 2018 19:18:44 +0200
[Message part 1 (text/plain, inline)]
My last mail seems to have been dropped. Maybe because of the attachment size?
I now gzipped the attachments.

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.gz (application/gzip, attachment)]
[fakechroot.new.gz (application/gzip, attachment)]
[signature.asc (application/pgp-signature, inline)]

This bug report was last modified 6 years and 265 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.