From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10155 invoked by alias); 26 Sep 2016 16:19:20 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 39445 Received: (qmail 25709 invoked from network); 26 Sep 2016 16:19:20 -0000 X-Qmail-Scanner-Diagnostics: from mail-pf0-f181.google.com by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.99.2/21882. spamassassin: 3.4.1. Clear:RC:0(209.85.192.181):SA:0(0.0/5.0):. Processed in 0.789551 secs); 26 Sep 2016 16:19:20 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=T_DKIM_INVALID autolearn=unavailable autolearn_force=no version=3.4.1 X-Envelope-From: schaefer@brasslantern.com X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: none (ns1.primenet.com.au: domain at brasslantern.com does not designate permitted sender hosts) 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== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:message-id:date:in-reply-to:comments :references:to:subject:mime-version; bh=75kQp/32QseZ0jbV5jkTn3gDRIs1yQw93j1IB+CnVCk=; b=cIN6mWyPSLdxRwzJ2s1hpPmbXs8KLrGc3PigqqLpmj6Dw+g1Ab3udBDL2Ma7oN5G2e BxU1nLe9blm6QmHG1dTobAQijrzCOTlGuK3MHFZwSggOq1Wjfoj1acSoMjqdCTJ2XeYf NoCgTbSLoAIuhHSTttBaUAa8YXUQa7/iBDHVDZ4+hnbKxjxl9snbJ0wHYMTUrL9hXLS/ kNsd/kuTrxLjaEn6wjRoFDqO6P9oPQ18WCeKk9m1DYo3Hmj8ajzqoLdoWF2fCi56aksE 4E7rsUKCVjm1qIgD8gh8JYJ7ABEBKlfahO2OHlEIkKDWzdkuKbOeLdmkpWQsjtJLsGvx +wlw== X-Gm-Message-State: AE9vXwM7TQrDz1r9pGuDLGZj+26lpEsH/RWyYyV0GTpuUgbFP/tnJmbzwEaUg+kgZvbfnA== X-Received: by 10.98.101.66 with SMTP id z63mr39579835pfb.59.1474906750428; Mon, 26 Sep 2016 09:19:10 -0700 (PDT) From: Bart Schaefer Message-Id: <160926091922.ZM26758@torch.brasslantern.com> Date: Mon, 26 Sep 2016 09:19:22 -0700 In-Reply-To: <20160926072546.GA28316@fujitsu.shahaf.local2> Comments: In reply to Daniel Shahaf "Re: PATCH: [for consideration] TMPSUFFIX" (Sep 26, 7:25am) References: <160925155112.ZM23899@torch.brasslantern.com> <20160926072546.GA28316@fujitsu.shahaf.local2> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh-workers@zsh.org Subject: Re: PATCH: [for consideration] TMPSUFFIX MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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.