Bug #129036 for File-Slurp: atomic write to unwritable file

Sat Apr 06 21:22:46 2019 user42_kevin [...] yahoo.com.au - Ticket created

Subject:	atomic write to unwritable file
Date:	Sun, 07 Apr 2019 11:22:39 +1000
To:	bug-File-Slurp [...] rt.cpan.org
From:	Kevin Ryde <user42_kevin [...] yahoo.com.au>

If a file does not have write permission, write_file() gets an error on attempting to rewrite it. But with the atomic option, it is rewritten successfully. Eg. use File::Slurp; system 'rm -f /tmp/unwritable'; system 'echo hello >/tmp/unwritable'; system 'chmod 000 /tmp/unwritable'; write_file('/tmp/unwritable', {atomic => 1}, "goodbye"); # succeeds In the interests of consistency, it'd be good for atomic to behave the same as ordinary in respect of file permissions. I'd think an error would be right. Perhaps atomic would test writable before starting the tempfile etc. Is faccessat() AT_EACCESS the closest test of sysopen O_WRONLY ability? Does "use filetest 'access'" give that to -w, or is that only plain access() going on real uid?

Sat Apr 06 22:10:16 2019 uri [...] stemsystems.com - Correspondence added

Subject:	Re: [rt.cpan.org #129036] atomic write to unwritable file
Date:	Sat, 6 Apr 2019 22:08:10 -0400
To:	bug-File-Slurp [...] rt.cpan.org
From:	Uri Guttman <uri [...] stemsystems.com>

On 4/6/19 9:22 PM, Kevin Ryde via RT wrote: Show quoted text

> If a file does not have write permission, write_file() gets an error on > attempting to rewrite it. But with the atomic option, it is rewritten > successfully. Eg. > > > In the interests of consistency, it'd be good for atomic to behave the > same as ordinary in respect of file permissions. > > I'd think an error would be right. Perhaps atomic would test writable > before starting the tempfile etc. Is faccessat() AT_EACCESS the closest > test of sysopen O_WRONLY ability? Does "use filetest 'access'" give > that to -w, or is that only plain access() going on real uid? >

that would open a race condition between the test of write access and the moving of the new file to the old one. not much you can do about that IMO. uri

Sat Apr 06 22:10:17 2019 The RT System itself - Status changed from 'new' to 'open'

Sun Apr 07 02:09:42 2019 user42_kevin [...] yahoo.com.au - Correspondence added

Subject:	Re: [rt.cpan.org #129036] atomic write to unwritable file
Date:	Sun, 07 Apr 2019 16:09:34 +1000
To:	bug-File-Slurp [...] rt.cpan.org
From:	Kevin Ryde <user42_kevin [...] yahoo.com.au>

"Uri Guttman via RT" <bug-File-Slurp@rt.cpan.org> writes: Show quoted text

> > that would open a race condition between the test of write access and > the moving of the new file to the old one. not much you can do about > that IMO.

Yes. I think I changed my mind too. I propose instead just notes in the docs. One of those describe the behaviour instead of anything heroic, occasionally dubious, forcing, etc, etc :-) : Note that rename has subtly different consequences on file permissions. You might have write permission on a file, but not create or rename permission in its directory, so atomic fails. Conversely, you might have directory permission so atomic can replace a file where you did not have ordinary write permission. Original file read/write/execute modes are replicated in the original, but the current implementation creates as owner and group of current process, losing original file owner and group.