From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4567 invoked by alias); 15 Jun 2017 08:42:53 -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: 41306 Received: (qmail 6607 invoked from network); 15 Jun 2017 08:42:53 -0000 X-Qmail-Scanner-Diagnostics: from mail-wr0-f177.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.128.177):SA:0(-1.0/5.0):. Processed in 0.793594 secs); 15 Jun 2017 08:42:53 -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=-1.0 required=5.0 tests=FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_PASS,T_DKIM_INVALID autolearn=unavailable autolearn_force=no version=3.4.1 X-Envelope-From: stephane.chazelas@gmail.com X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: pass (ns1.primenet.com.au: SPF record at _netblocks.google.com designates 209.85.128.177 as permitted sender) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-disposition:in-reply-to:user-agent; bh=+p/4UzyK019gKtgjgWhH//5vz0IiBH9khhLG2zY4jcw=; b=adA8fpIC1IcdCZnKx8G7HAvF3C3g0LixFriRuj/N0lbwFWksytrbcxZZGNnyGA0nzb /DNMMN8qDzq9dmg5mrM2rarI5d5RwIF//tsfniVgXuUuPjfdnZqcQLTxtb5S+ivpHPj0 YNc2jDiy4/WlvPe6RGe+XfVV6UvUS2vLZl/Vj/EStFcqlKm0CzX4zk/LUPMPZ3pBxeFu WEolKNbAgbyUZHcwcVQ1y0JTFAk2OwiHIOliUJOREBYfTxfJHbz3jnsbRLgRid5Jxv4H S4VZ17/j+4P14byaYmON3yoYzdRmTyiJybFB0zl7w/tLyFzBrFP5t0iqxXDQeYNo0Oz6 9PAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :in-reply-to:user-agent; bh=+p/4UzyK019gKtgjgWhH//5vz0IiBH9khhLG2zY4jcw=; b=tuz79onqpj98TX5OMvB1N6+REGEbsfQtVK3gADTerarAN5+Ok6KYKRJgPx33JHF88K hkqeKA1MxAGwS3qScrdKTcCNN+NpIk7FUNhv8kuEpakVzFCa1pfXIgBuNJ1D6dumNwt0 e4MayXNeCkdRJXkf/d0//2if9ia0ANp7SXQWqNZ8aJu4l2Oad5iE5I2MSgoGdMORb9Ox shKwrTECHRa4No0MzppDQ9dMMkwdHfKt1TyerxIwhUbIFqsfDwN5b7mnqn5K795ksKT6 F+HQ1P/VGsadvW/FVDtWGIjNNzhJf0uJd8K7dEb/erUGD2kQAS7LUYRybr1KTq8HZdXS i1RQ== X-Gm-Message-State: AKS2vOyQttpdXcG9ahygpks6VLYzV5B08U/KGsV95ZGZIk/Cv1YgwAi1 IJl+aPp+LtMZYa7x X-Received: by 10.223.176.253 with SMTP id j58mr2710212wra.65.1497516166876; Thu, 15 Jun 2017 01:42:46 -0700 (PDT) Date: Thu, 15 Jun 2017 09:42:44 +0100 From: Stephane Chazelas To: Bart Schaefer Cc: "zsh-workers@zsh.org" Subject: Re: [PATCH3] Re: avoid closed stdin() in zle widgets Message-ID: <20170615084244.GB2416@chaz.gmail.com> Mail-Followup-To: Bart Schaefer , "zsh-workers@zsh.org" References: <20170611182045.GA5318@chaz.gmail.com> <20170612060554.GA4709@chaz.gmail.com> <1497278089.1853864.1006670720.0A8DB74D@webmail.messagingengine.com> <20170612151042.GB3806@chaz.gmail.com> <20170612151902.GA19315@chaz.gmail.com> <1497281675.1868175.1006750384.46FA1223@webmail.messagingengine.com> <20170612190218.GA12445@chaz.gmail.com> <170614154425.ZM20199@torch.brasslantern.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <170614154425.ZM20199@torch.brasslantern.com> User-Agent: Mutt/1.5.24 (2015-08-30) 2017-06-14 15:44:25 -0700, Bart Schaefer: > On Jun 12, 8:02pm, Stephane Chazelas wrote: > } > } My point is that a command should be able to reasonably make some > } assumptions, like: > } > } - stdin should be open for at least reading > } - stdout, stderr should be open for at least writing > > Although I understand the security implication of accidentally opening > some other file onto fd 0/1/2, I can't agree with the above statements. > Taken to the logical conclusion, the >&- <&- or 2>&- operators would > be required always to fail with an error. > > It should not be the shell's job to plug this hole. I will agree that > a valid argument is that the shell should not implicitly *open* this > hole, which one could also argue is what the completion system had > been doing in spite of the behavior being documented. However, with > these two likely exceptions -- > > } - argv[0] should be set (argc > 0) > } - no dups in the environment > > -- there is nothing else on your list where I would agree that the > shell should ignore the user's directives in the name of protecting > an external command from itself. I think you misinterpreted what I said, I did not imply that the shell should take upon itself to prevent users from creating those pathological conditions, but that it should not take upon itself to creating those pathological conditions itself. That's the "Be conservative in what you do" in the "Be conservative in what you do, be liberal in what you accept from others" (and yes, it's a case where "dircolors" did not fully apply the "be liberal in what you accept"). In other words, I would certainly not want zsh to refuse to <&- just like I would not want close(0) in C to fail. I would even welcome new options to the "env" utility to execute a command without arguments or with arbitrary argv[0], or with duplicate env vars or with env strings without = characters so one can test applications in those pathological conditions (and possibly raise awareness on the security implications), but if we put aside those testing cases, an application like zsh should not intentionaly (by itself) cause those pathological conditions. The case of zle widgets running commands with stdin close was not a case where the user requested stdin to be closed. > } $ (limit stacksize 100k; zsh) > } zsh: segmentation fault > } zsh: segmentation fault > } > } (twice!?). Is that a bug? > > I believe what's happening is that both the zsh inside the subshell > and the parent handling the subshell exit are reporting the error, > so one failure / two messages. > > However, I can't test directly because I can start zsh -f with a hard > limit stack size of *zero*, so I'm quite curious as to why you get a > crash on 100k. I suspect your system won't bring the stack size below some threshold (or just ignores that limit). With a null stack size, you woudn't even be able to call execve() My several segvs were probably down to some child processes spawned by my ~/.zshrc dying there upon stack overflow. The point was just an illustration that you can't always deal with all pathological conditions, you have to put a limit on the amount of effort you're willing to put into covering for all possible pathological cases, and IMO a closed stdin is one such pathological case (even if not as much as a very small stack size, or random memory bit flips), and one you can blame on the calling application. -- Stephane