GNU bug report logs - #12366
[gnu-prog-discuss] Writing unwritable files

Previous Next

Full log

View this message in rfc822 format

From: Paolo Bonzini <bonzini <at> gnu.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 12366 <at> debbugs.gnu.org, gnu-prog-discuss <at> gnu.org, John Darrington <john <at> darrington.wattle.id.au>
Subject: bug#12366: [gnu-prog-discuss] Writing unwritable files
Date: Thu, 06 Sep 2012 18:24:29 +0200

Il 06/09/2012 18:11, Paul Eggert ha scritto:
>> > I consider "shuf foo -o foo" (on a read-write file) to be insecure.
>> > Besides, it works by chance
> It's not by chance.  shuf is designed to let you
> shuffle a file in-place, and is documented to work,
> by analogy with "sort -o foo foo".  If we ever
> change "shuf" to use mmap, we'll make
> sure it continues to work in-place.

Yeah, I read that from Padraig.  I stand corrected.

> I'm not sure what is meant by "insecure" here.
> Of course there are race conditions if other
> processes modify a file when "shuf"
> reads or writes it, but that's true for pretty
> much any program that reads or writes any file,
> including sed -i.

No, unlink/rename "sed -i" replaces the file atomically.  A program that
reads the target file will never be able to observe an intermediate
result.  This is not true of "shuf -o foo foo".

(In addition, the temporary file for "sed -i" is opened with 0400
permissions for the user running sed, and will not have the same
owner/group/ACL/context as the target file until just before renaming to
the destination).

It's mostly paranoia, but the race window _is_ there unless you use
rename and break hard links.

Paolo

Previous Next

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