GNU bug report logs -
#12366
[gnu-prog-discuss] Writing unwritable files
Previous Next
Reported by: Paolo Bonzini <bonzini <at> gnu.org>
Date: Thu, 6 Sep 2012 12:14:01 UTC
Severity: normal
Done: Jim Meyering <meyering <at> hx.meyering.net>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
[For bug-coreutils: the context here is that sed -i, just like perl -i,
breaks hard links and thus destroys the content of files with 0400
permission].
Il 06/09/2012 12:38, John Darrington ha scritto:
> That's expected of programs that break hard links.
>
> I wonder how many users who are not hackers expect it? I suspect most
> would not.
>
> Why is it not possible or not desirable to check the mode of the file
> before renaming?
Because there are valid use cases in which you _want_ to break hard links.
Also because it would be twice as slow and require twice as much disk
space. The choices would be:
1) copy the input file to a temporary file, then write to the original
file while processing the copy; required space = input_size +
max(input_size, output_size)
2) write to a temporary file while processing the original, then copy it
over to the input; required space = output_size + max(input_size,
output_size).
3) same as (1) or (2) with memory replacing a temporary file. Goes
totally against the idea of sed as a _stream_ editor.
> Here is what the sed manual thinks.
>
> Thanks for pointing that out (it must be a recent addition; my installed
> version doesn't have this text).
Actually it is older than the version control repository, so 2004 or
older. But it is under "Reporting bugs", not under the -i option
(patches welcome ;)).
You'll also find it under /usr/share/doc/sed-4.2.1/BUGS.
> `-i' clobbers read-only files
> In short, `sed -i' will let you delete the contents of a read-only
> file, and in general the `-i' option (*note Invocation: Invoking
> sed.) lets you clobber protected files. This is not a bug, but
> rather a consequence of how the Unix filesystem works.
>
> The permissions on a file say what can happen to the data in that
> file, while the permissions on a directory say what can happen to
> the list of files in that directory. `sed -i' will not ever open
> for writing a file that is already on disk. Rather, it will work
> on a temporary file that is finally renamed to the original name:
> if you rename or delete files, you're actually modifying the
> contents of the directory, so the operation depends on the
> permissions of the directory, not of the file. For this same
> reason, `sed' does not let you use `-i' on a writeable file in a
> read-only directory, and will break hard or symbolic links when
> `-i' is used on such a file.
>
> I don't think that this addresses the issue at hand. The program does something
> non-intuitive that can lead to loss of data, and it wouldn't be reasonable to blame
> the user in that instance.
I agree, but it's not me who designed the Unix filesystem permissions.
> (Some) other GNU programs don't behave like this. For
> example "truncate foo" on a readonly foo will exit with an error
Truncate does not process foo for input at the same time, so it isn't't
really relevant.
> , as will "dd if=foo of=foo count=10".
dd has a well-defined behavior for overlapping input and output, and
this well-defined behavior in fact mandates that dd doesn't break hard
links.
> Likewise, "shuf foo -o foo".
I consider "shuf foo -o foo" (on a read-write file) to be insecure.
Besides, it works by chance just because it reads everything in memory
first. If it used mmap to process the input file, "shuf foo -o foo"
would be broken, and the only way to fix it would be to do the same as
"sed -i".
shuf could in fact introduce a "shuf -i" mode that would be consistent
with the way "sed -i" works, including the ability to create a backup
file _and_ the breaking of hard links.
Paolo
This bug report was last modified 12 years and 232 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.