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