On Sun, Feb 2, 2014 at 4:43 PM, David Levine wrote:
Documented where? SUSv3 calls out the behaviour explicitly, as
inherited from the ISO C spec.
Well, the SUSv2 spec says:
If the link named by the new argument exists, it shall be removed
and old renamed to new. In this case, a link named new shall
remain visible to other processes throughout the renaming
operation and refer either to the file referred to by new or old
before the operation began.
and that's what Linux still uses for its documentation.
For which manpage. CentOS 5 system for rename(2):
If newpath already exists it will be atomically replaced (subject to a
few conditions; see ERRORS below), so that there is no point at which
another process attempting to access newpath will find it missing.
What you quote is not well written and is not clear on what really may
happen. My understanding is that rename() is atomic and safe, hence I felt
there was no real security risk when I included the operation years ago for
suffix support.
I know you tried to explain to me via private email why there was still a
security risk, but I still do not understand it. If there is a risk, it
would be due to old and/or faulty implementations of the underlying OS
compared to the way a rename() operation is supposed to work.
I know it may be all academic now, but the practice of renaming temp files
into "persistent" files is a common practice, like to avoid symlink attacks.
Rename() is atomic and should overwrite any existing file with the same
name. If a process had the file open before it is overwritten due to
rename(), that process will only have a handle to the old file and not the
new one.
--ewh
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers