Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: PATCH: [for consideration] TMPSUFFIX
- X-seq: zsh-workers 39445
- From: Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>
- To: zsh-workers@xxxxxxx
- Subject: Re: PATCH: [for consideration] TMPSUFFIX
- Date: Mon, 26 Sep 2016 09:19:22 -0700
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed;        d=brasslantern-com.20150623.gappssmtp.com; s=20150623;        h=from:message-id:date:in-reply-to:comments:references:to:subject         :mime-version;        bh=75kQp/32QseZ0jbV5jkTn3gDRIs1yQw93j1IB+CnVCk=;        b=HvXWbxA4i4IsHk0DhWBLYq4Lq2+11RuIBaEcL8kR+8N5DeDqGZQGPHHyQ71W7FcGCv         qJkDmPTGWg+5O0Kv7TcXUI2PVsP93w84jAUDEQkiVJwIN8dhLsiAc/Z0C6k5q8tUjH84         W8Qz5f9SNDc0xTnqitOO/7QCMEM2bzyi4umeGuxDLue7f5mXs9XcKp5x9AIwK3urlciJ         ZJMBV4EW/ig3FNK+uWiSZxRTJK0ogyClEx32Oso9CNCNfvgXzEwiVirZNfiet/fwlAO0         cfReZKHzghNHQy7CTprAOvDGXbszGeenrJPvgSbZeL2YzLrkjinASTAxpjJaAwNhJSc8         KWzw==
- In-reply-to: <20160926072546.GA28316@fujitsu.shahaf.local2>
- List-help: <mailto:zsh-workers-help@zsh.org>
- List-id: Zsh Workers List <zsh-workers.zsh.org>
- List-post: <mailto:zsh-workers@zsh.org>
- Mailing-list: contact zsh-workers-help@xxxxxxx; run by ezmlm
- References: <160925155112.ZM23899@torch.brasslantern.com> 	<20160926072546.GA28316@fujitsu.shahaf.local2>
On Sep 26,  7:25am, Daniel Shahaf wrote:
} Subject: Re: PATCH: [for consideration] TMPSUFFIX
}
} This looks like a race condition: if another process creates the
} filename that mktemp() returned before the open(O_EXCL) call [which will
} therefore fail], zsh will remove that filename even though zsh didn't
} create it.
If another process creates the filename that mktemp() returned, we have
a much larger problem -- the whole point is that it should be impossible
for another process to create that name first.
} [This could trigger through a deliberate attack or through
} a race condition between two zsh instances calling =(:) concurrently.]
It definitely CANNOT occur because of two zsh instances using =().  I
won't assert the attack is 100% impossible, but there's nothing more
we can do about that than we already have.
So mostly we're concerned with $TMPDIR being unwritable, or full file
system, etc. -- but of course failure for any other reason including
attacker-duplicated file name would get swept up if we change the way
failure is handled.
} I don't get "the caller will create the file".  [...]
} (The caller can call getoutputfile() again if he wishes.)
The SHELL SCRIPT caller, not the C code caller.  That is, as currently
coded, =(...) will substitute a file name whether or not it actually got
created.  In a case like
    () { ... do something with $1 ... } =(contents)
the name in $1 could be used in output redirections, etc.  As written,
exec.c seems intended to allow this.
} How is it helpful to return a filename, which may or may not exist and
} certainly doesn't contain the output of 'cmd'? It seems to me erroring
} out would be better.
It'd have to be an error on the same order as "bad substitution" so the
whole command context fails.  Hence bringing it up for discussion.
} The patch creates two hard links to the file but only removes one of
} them.
Oops, design iteration error -- I first used rename() instead of link()
until I realized that would allow e.g. TMPSUFFIX="/../other/filesystem" 
which would invoke an implicit copy and invalidate the file descriptor.
Didn't put back the original addfilelist().  Thanks for noticing, will
fix in next iteration after we resolve the error-handling question.
Messages sorted by:
Reverse Date,
Date,
Thread,
Author