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 [email protected] https://lists.nongnu.org/mailman/listinfo/nmh-workers
