[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Nmh-workers] extensions on tmp filenames?

From: Earl Hood
Subject: Re: [Nmh-workers] extensions on tmp filenames?
Date: Sun, 2 Feb 2014 17:23:07 -0600

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]