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.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 12366 in the body.
You can then email your comments to 12366 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-coreutils <at> gnu.org:
bug#12366; Package
coreutils.
(Thu, 06 Sep 2012 12:14:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Paolo Bonzini <bonzini <at> gnu.org>:
New bug report received and forwarded. Copy sent to
bug-coreutils <at> gnu.org.
(Thu, 06 Sep 2012 12:14:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[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
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#12366; Package
coreutils.
(Thu, 06 Sep 2012 12:32:02 GMT)
Full text and
rfc822 format available.
Message #8 received at submit <at> debbugs.gnu.org (full text, mbox):
On 09/06/2012 01:12 PM, Paolo Bonzini wrote:
> [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.
Well `sort` and `shuf` need to read all their input before
generating output. This is traditional behavior and
POSIX also states that -o can refer to one of the input files.
Also related to this is having a seperate "replace" wrapper,
that would handle all the atomic, backup, permission, ... issues.
http://www.pixelbeat.org/docs/unix_file_replacement.html
I takes advantage of the existing coreutils to handle the above.
I really need to polish that off and submit it
(translations in the shell script was one thing that was bothering me).
I notice David Wheeler proposed much the same thing
with the "rewrite" util (I like that name too):
http://permalink.gmane.org/gmane.comp.standards.posix.austin.general/5348
cheers,
Pádraig
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#12366; Package
coreutils.
(Thu, 06 Sep 2012 12:41:03 GMT)
Full text and
rfc822 format available.
Message #11 received at submit <at> debbugs.gnu.org (full text, mbox):
Il 06/09/2012 14:30, Pádraig Brady ha scritto:
>>
>> 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.
>
> Well `sort` and `shuf` need to read all their input before
> generating output.
Yes, but they could use mmap instead of a single large buffer to cope
with files that are bigger than the available memory, but smaller than
the address space.
> This is traditional behavior and
> POSIX also states that -o can refer to one of the input files.
Interesting, thanks!
Paolo
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#12366; Package
coreutils.
(Thu, 06 Sep 2012 12:45:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 12366 <at> debbugs.gnu.org (full text, mbox):
On September 6, 2012 at 2:12 PM Paolo Bonzini <bonzini <at> gnu.org> wrote:
> [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].
I consider this being 2 different cases:
* 'sed -i' breaks hard links:
That's because it places the output at place where
the input file was (by unlink+rename).
That's okay IMO.
* 'sed -i' destroys the content of files with 0400 perms:
That's a bug IMHO. sed should open the input file read-write.
If that fails, then the input won't change with a nice diagnostic.
In 'sort -o', we recently added a similar check right at the beginning
to avoid useless processing possibly leading to an error afterwards:
see http://bugs.gnu.org/11816 with the commit
http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commit;h=44fbd3fd862e34d42006f8b74cb11c9c56346417
<http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commit;h=44fbd3fd862e34d42006f8b74cb11c9c56346417>
Have a nice day,
Berny
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#12366; Package
coreutils.
(Thu, 06 Sep 2012 13:28:03 GMT)
Full text and
rfc822 format available.
Message #17 received at 12366 <at> debbugs.gnu.org (full text, mbox):
Paolo Bonzini wrote:
> [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].
Did I misunderstand how "destroy" is used above?
$ echo important > k
$ chmod a-w k
$ sed -i s/./X/ k
$ cat k
XXXXXXXXX
$ ls -og k
-r--------. 1 10 Sep 6 15:23 k
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#12366; Package
coreutils.
(Thu, 06 Sep 2012 16:13:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 12366 <at> debbugs.gnu.org (full text, mbox):
On 09/06/2012 05:12 AM, Paolo Bonzini wrote:
> 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.
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.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#12366; Package
coreutils.
(Thu, 06 Sep 2012 16:25:01 GMT)
Full text and
rfc822 format available.
Message #23 received at 12366 <at> debbugs.gnu.org (full text, mbox):
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
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#12366; Package
coreutils.
(Thu, 06 Sep 2012 16:37:01 GMT)
Full text and
rfc822 format available.
Message #26 received at 12366 <at> debbugs.gnu.org (full text, mbox):
On 09/06/2012 09:24 AM, Paolo Bonzini wrote:
> A program that reads the target file will never
> be able to observe an intermediate result.
Sure, but that doesn't fix the race condition I
mentioned. If some other process is writing F
while I run 'sed -i F', F is not replaced atomically.
That's true even if the other process is another
instance of 'sed'.
While 'sed -i' solves some race conditions,
it doesn't even come close to solving them all.
Fixing this problem in general is above
sed's pay grade, just as it's above shuf's.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#12366; Package
coreutils.
(Thu, 06 Sep 2012 16:40:03 GMT)
Full text and
rfc822 format available.
Message #29 received at 12366 <at> debbugs.gnu.org (full text, mbox):
Il 06/09/2012 18:35, Paul Eggert ha scritto:
>> > A program that reads the target file will never
>> > be able to observe an intermediate result.
> Sure, but that doesn't fix the race condition I
> mentioned. If some other process is writing F
> while I run 'sed -i F', F is not replaced atomically.
How not so?
Paolo
> That's true even if the other process is another
> instance of 'sed'.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#12366; Package
coreutils.
(Thu, 06 Sep 2012 17:01:02 GMT)
Full text and
rfc822 format available.
Message #32 received at 12366 <at> debbugs.gnu.org (full text, mbox):
>> If some other process is writing F
>> while I run 'sed -i F', F is not replaced atomically.
> How not so?
For example:
echo ac >f
sed -i 's/a/b/' f &
sed -i 's/c/d/' f
wait
cat f
If 'sed' were truly atomic, then the output of this would
always be 'bd'. But it's not.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#12366; Package
coreutils.
(Thu, 06 Sep 2012 17:13:02 GMT)
Full text and
rfc822 format available.
Message #35 received at 12366 <at> debbugs.gnu.org (full text, mbox):
Paul Eggert wrote:
> >> If some other process is writing F
> >> while I run 'sed -i F', F is not replaced atomically.
>
> > How not so?
>
> For example:
>
> echo ac >f
> sed -i 's/a/b/' f &
> sed -i 's/c/d/' f
> wait
> cat f
>
> If 'sed' were truly atomic, then the output of this would
> always be 'bd'. But it's not.
The file replacement is atomic. The reading of the file is not.
Bob
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#12366; Package
coreutils.
(Thu, 06 Sep 2012 17:24:01 GMT)
Full text and
rfc822 format available.
Message #38 received at 12366 <at> debbugs.gnu.org (full text, mbox):
On 09/06/2012 10:12 AM, Bob Proulx wrote:
> The file replacement is atomic. The reading of the file is not.
Sure, but the point is that from the end user's
point of view, 'sed -i' is not atomic, and can't
be expected to be atomic.
'sed -i' and 'sort -o' both use some atomic operations
internally, but neither is atomic overall. Users who
want atomicity must look elsewhere, or implement it
themselves.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#12366; Package
coreutils.
(Thu, 06 Sep 2012 17:36:01 GMT)
Full text and
rfc822 format available.
Message #41 received at 12366 <at> debbugs.gnu.org (full text, mbox):
On September 6, 2012 at 7:23 PM Paul Eggert <eggert <at> cs.ucla.edu> wrote:
> On 09/06/2012 10:12 AM, Bob Proulx wrote:
> > The file replacement is atomic. The reading of the file is not.
>
> Sure, but the point is that from the end user's
> point of view, 'sed -i' is not atomic, and can't
> be expected to be atomic.
>
> 'sed -i' and 'sort -o' both use some atomic operations
> internally, but neither is atomic overall. Users who
> want atomicity must look elsewhere, or implement it
> themselves.
Why can't 'sed -i' be made atomic for the user?
Today, it creates a temporary file for the output.
At the end, it calls rename(). What if it instead
rewinds the input and that temporary file and copies
it's content to the input file?
Okay, this is slower than a rename(), but it would
write into the same inode. To preserve today's behaviour,
this could be done with a new option like --in-place-same.
Just a thought.
Have a nice day,
Berny
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#12366; Package
coreutils.
(Thu, 06 Sep 2012 18:22:02 GMT)
Full text and
rfc822 format available.
Message #44 received at 12366 <at> debbugs.gnu.org (full text, mbox):
On Thu, 6 Sep 2012, Paolo Bonzini wrote:
>
>> 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
POSIX rename assures that the destination path always exists if it
already existed. If unlink/ln was used, then the destination path
would temporarily be missing. While 'rename' is occuring, a second
(parallel) reader/writer has no idea which version will be accessed.
Microsoft Windows and other operating systems might not support the
POSIX sematic.
Certain filesystems (or their implementation) might not support atomic
'rename'.
> It's mostly paranoia, but the race window _is_ there unless you use
> rename and break hard links.
Yes, you must use rename, and rename would need to work as per the
POSIX specification.
Bob
--
Bob Friesenhahn
bfriesen <at> simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#12366; Package
coreutils.
(Thu, 06 Sep 2012 18:24:02 GMT)
Full text and
rfc822 format available.
Message #47 received at 12366 <at> debbugs.gnu.org (full text, mbox):
On 09/06/2012 10:35 AM, Bernhard Voelker wrote:
> Why can't 'sed -i' be made atomic for the user?
> Today, it creates a temporary file for the output.
> At the end, it calls rename(). What if it instead
> rewinds the input and that temporary file and copies
> it's content to the input file?
That's kind of what 'sort -o' does, and it also
has race conditions. For example, in that last phase
while it's copying the content to the input file, some other
process might be reading the input file.
There is no good general and portable atomic solution to
this sort of problem, not in POSIX anyway. Practical
implementations of utilities like 'sed' and 'sort'
and 'shuf' all involve races of some sort or another.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#12366; Package
coreutils.
(Thu, 06 Sep 2012 20:07:01 GMT)
Full text and
rfc822 format available.
Message #50 received at 12366 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Thu, Sep 06, 2012 at 11:23:21AM -0700, Paul Eggert wrote:
On 09/06/2012 10:35 AM, Bernhard Voelker wrote:
> Why can't 'sed -i' be made atomic for the user?
> Today, it creates a temporary file for the output.
> At the end, it calls rename(). What if it instead
> rewinds the input and that temporary file and copies
> it's content to the input file?
That's kind of what 'sort -o' does, and it also
has race conditions. For example, in that last phase
while it's copying the content to the input file, some other
process might be reading the input file.
I don't think that matters. In fact I like to be able to use
tail -f to see what's being written to a file, and find it
the mozilla like behaviour, where I have to wait until the
entire file is downloaded in order to see the first byte,
rather annoying.
J'
--
PGP Public key ID: 1024D/2DE827B3
fingerprint = 8797 A26D 0854 2EAB 0285 A290 8A67 719C 2DE8 27B3
See http://keys.gnupg.net or any PGP keyserver for public key.
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#12366; Package
coreutils.
(Thu, 06 Sep 2012 21:02:02 GMT)
Full text and
rfc822 format available.
Message #53 received at 12366 <at> debbugs.gnu.org (full text, mbox):
Il 06/09/2012 20:21, Bob Friesenhahn ha scritto:
>>
>> No, unlink/rename "sed -i" replaces the file atomically. A program that
>
> POSIX rename assures that the destination path always exists if it
> already existed.
My bad, I meant link-breaking/rename. Of course you must not unlink first.
Paolo
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#12366; Package
coreutils.
(Fri, 07 Sep 2012 16:39:01 GMT)
Full text and
rfc822 format available.
Message #56 received at 12366 <at> debbugs.gnu.org (full text, mbox):
Il 06/09/2012 19:23, Paul Eggert ha scritto:
>> > The file replacement is atomic. The reading of the file is not.
> Sure, but the point is that from the end user's
> point of view, 'sed -i' is not atomic, and can't
> be expected to be atomic.
Atomic file replacement is what matters for security.
Paolo
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#12366; Package
coreutils.
(Fri, 07 Sep 2012 19:48:02 GMT)
Full text and
rfc822 format available.
Message #59 received at 12366 <at> debbugs.gnu.org (full text, mbox):
On 09/07/2012 09:38 AM, Paolo Bonzini wrote:
> Atomic file replacement is what matters for security.
Unfortunately, 'sed's use of atomic file replacement does not
suffice for security.
For example, suppose sysadmins (mistakenly) followed the practice of
using 'sed -i' to remove users from /etc/passwd. And suppose there
are two misbehaving users moe and larry, and two sysadmins bonzini and
eggert. bonzini discovers that moe's misbehaving, and types:
sed -i '/^moe:/d' /etc/passwd
and thinks, "Great! moe can't log in any more." Similarly eggert
discovers that larry's misbehaving, and types:
sed -i '/^larry:/d' /etc/passwd
and thinks, "All right! I've done my job too."
Unfortunately, it could be that moe can still log in afterwards. Or
maybe larry can. We don't know, because 'sed -i' is not atomic, which
means /etc/passwd might contain moe afterwards, or maybe larry.
Of course one could wrap 'sed -i' inside a larger script, that
arranges for atomicity at the end-user level. But the same is true
for 'sort -o'. Perhaps the method of 'sed -i' buys the user
*something*, but whatever that something is, isn't immediately
obvious. When it comes to security mechanisms, simplicity and clarity
are critical, and unfortunately 'sed -i' has problems in this area,
just as 'sort -o' does.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#12366; Package
coreutils.
(Fri, 07 Sep 2012 20:44:01 GMT)
Full text and
rfc822 format available.
Message #62 received at 12366 <at> debbugs.gnu.org (full text, mbox):
Paul Eggert wrote:
> Paolo Bonzini wrote:
> > Atomic file replacement is what matters for security.
>
> Unfortunately, 'sed's use of atomic file replacement does not
> suffice for security.
>
> For example, suppose sysadmins (mistakenly) followed the practice of
> using 'sed -i' to remove users from /etc/passwd. And suppose there
> are two misbehaving users moe and larry, and two sysadmins bonzini and
> eggert. bonzini discovers that moe's misbehaving, and types:
>
> sed -i '/^moe:/d' /etc/passwd
Using /etc/passwd isn't a good example because system convention
dictates that a /etc/passwd.lock must be observed for any edits there
specifically for the problem you are illustrating. The above would
not be correct even if sed were fully atomic overall.
> Of course one could wrap 'sed -i' inside a larger script, that
> arranges for atomicity at the end-user level.
Right. The 'vipw' script for example. :-)
[I have abused the EDITOR variable for that purpose many times. Set it
to either an inline script or to a real script and use it to safely
edit these types of files. More with 'visudo' though.]
Bob
Reply sent
to
Jim Meyering <meyering <at> hx.meyering.net>:
You have taken responsibility.
(Sun, 07 Oct 2012 09:14:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Paolo Bonzini <bonzini <at> gnu.org>:
bug acknowledged by developer.
(Sun, 07 Oct 2012 09:14:02 GMT)
Full text and
rfc822 format available.
Message #67 received at 12366-done <at> debbugs.gnu.org (full text, mbox):
This has been beaten to death, and is IMHO not indicative
of a coreutils problem, so I've marked this issue as "done".
If anyone wants to add a TODO item or something like that,
please be precise and reopen the issue.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Sun, 04 Nov 2012 12:24:04 GMT)
Full text and
rfc822 format available.
This bug report was last modified 12 years and 231 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.