No tempFile() in std.file

H. S. Teoh via Digitalmars-d-learn digitalmars-d-learn at puremagic.com
Tue May 16 08:06:13 PDT 2017


On Tue, May 16, 2017 at 06:56:57AM -0700, Jonathan M Davis via Digitalmars-d-learn wrote:
> On Tuesday, May 16, 2017 11:19:14 bachmeier via Digitalmars-d-learn wrote:
> > On Monday, 15 May 2017 at 22:38:15 UTC, Jonathan M Davis wrote:
> > > I suppose that we could add a tempFile that did what
> > > std.stdio.File.scratchFile did but create an empty file and return
> > > its path rather than returning a File, though that would be a bit
> > > annoying, since you'd then have to open it to operate on it
> > > instead of just writing to it. Maybe it would be worth doing
> > > though given the stupidity blocking std.stdio.File.scratchFile.
[...]

Don't forget that there are security concerns related to this.  Most
modern OS APIs tend to prefer a temp file creation call that atomically
(1) generates a unique filename and (2) creates a file with said
filename with permissions set such that it can only be exclusively used
by the calling process.

The reason for this is that there is a race condition between the
generation of the filename and the creation of the file. On Posix, for
example, an attacker could guess the generated filename and preemptively
create the temp file with unexpected content that may cause the program
to malfunction (usually to trigger another security flaw and thereby
cause arbitrary code execution or privilege escalation, etc.), or to
substitute a symlink that points to a file the program shouldn't be
writing to / reading from (e.g., /etc/passwd).  Actual exploits have
been carried out using this route, hence it's something application
programmers need to be aware of.

(Note that even if your program doesn't do anything directly security
related, it may still be an issue; e.g., it could be a music player but
an attacker could potentially leverage it to read sensitive files by
redirecting file operations or cause a malfunction that gives the
attacker escalation of privileges, e.g., a remote attacker gaining shell
access on a local user account, from which further attacks can be
launched. In this day and age of advanced exploits being widely
disseminated over the 'net, these scenarios are far more likely than
we'd like to think.)


T

-- 
Без труда не выловишь и рыбку из пруда. 


More information about the Digitalmars-d-learn mailing list