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.
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 f
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/p
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.
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.
Pa
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
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/
