GNU bug report logs -
#27986
26.0.50; `rename-file' can rename files without confirmation
Previous Next
Reported by: Philipp <p.stephani2 <at> gmail.com>
Date: Sun, 6 Aug 2017 15:41:02 UTC
Severity: important
Tags: security
Found in version 26.0.50
Done: Paul Eggert <eggert <at> cs.ucla.edu>
Bug is archived. No further changes may be made.
Full log
Message #11 received at 27986 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
>> Probably the test for case-insensitive file names should be
>> removed altogether
>
> Which one? there are two of them.
There should be just one such test, since it's testing the same thing and
there's no point to doing the same test twice. And I notice the code has some
other duplicate system calls. I installed the attached patch, which prunes away
some of these duplicates. With this patch, (rename-file "a" "b/") now takes just
one system call on recent GNU/Linux, whereas it used to take four (and was not
atomic).
However, even with this patch there are races on GNU/Linux which can lead to
potential security problems. Perhaps we can't fix these races on MS-Windows but
we should be able to fix them on a GNUish host. However, we will need to change
the semantics of rename-file etc. slightly, since no single system call supports
the cp-like target rewriting of these functions. I have a fix in mind to do that
in a hopefully compatible-enough way, which I'll try to propose soon. I'll keep
case-insensitive file systems in mind when I do that.
This reminds me of a similar problem in GNU coreutils which I fixed a dozen
years ago by adding the -T option to mv, ln, etc.
[0001-Improve-performance-for-rename-file-etc.patch (text/x-patch, attachment)]
This bug report was last modified 7 years and 257 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.