From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5998 invoked by alias); 11 Mar 2018 15:17:52 -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: List-Unsubscribe: X-Seq: 42446 Received: (qmail 3583 invoked by uid 1010); 11 Mar 2018 15:17:52 -0000 X-Qmail-Scanner-Diagnostics: from mail-wr0-f178.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.178):SA:0(-1.9/5.0):. Processed in 2.284506 secs); 11 Mar 2018 15:17:52 -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.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_PASS,T_DKIM_INVALID autolearn=ham autolearn_force=no version=3.4.1 X-Envelope-From: stephane.chazelas@gmail.com X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:subject:message-id:mail-followup-to:mime-version :content-disposition:user-agent; bh=b3f6Ui5S90gjQ29tH4ebPDSJsfSl2090B/ifeJeUIXk=; b=VF9zYRXkCpotxP8rHRZ65rOooPVFWHe4KAIZ2PAPQ41fm5xmcYpkFaxS3RoC3hz2hp JyVE4GptluXg6yqxF0xuMimagJhLYZWxfwhIYxT0+twwVyEjGdv2SsZ/YNGaBm+oWQUD tow2XPXnG3kAtTd2frd1IPJIkhw0FOuVKDdDt07bsvGA7ZtqxuKYz9LFEwNBuvjwhjrR vwgRgvQvQCUIfsAKLBHWgiSCqfXcLM4q9iEDlpQWVJ+Dt4nFXzihBSI3mrlVbTYl8OMu bz1+VXK8I1UfITGmgOJrc7H7QnC2IIFffD1NPuuJyLDwsQZV5Lzd90NrL0L4eclUSxD6 mDTA== 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:subject:message-id:mail-followup-to :mime-version:content-disposition:user-agent; bh=b3f6Ui5S90gjQ29tH4ebPDSJsfSl2090B/ifeJeUIXk=; b=AgT0GhaJoRbYpShTZoQrL6tLlUJ5jUtLLnsSEDHH/LpLlgVaRWrrUchlztcWyxrB8A isWntfMINZOnhh7bknW/0pOx5BA1/ZzoqjybxKiBNYZ1yutXOrzIfHCtiCObxSU93xNq H/L5ckO31QPQ8Do3j70JK2o/ms/NFyEdaXRIF5gcMqWZ8RM+MTpjBdJVliLWY28yrTFT lHFwoDRdmZHv90ponl3FPA2m5cQj3EAj5TTNxrUq3Iq1krYhsy0rnSN8+6vmZKAojcqV n62QtQNF18pqeM12GUrjpW/dNnTkg4j8lbmdIDBR6qi+zlrKLPTrqXu+DMSUy3+U9AJ/ mGoQ== X-Gm-Message-State: AElRT7GVYfFmW8MkgxKX6nncnewRX5AwM+bi+XgmTC4BHaOWZNaFtZLH Ddhd4x5ULp3wMNH+b+/pHl8= X-Google-Smtp-Source: AG47ELuUIqR+Z/r0PqhGS8KD1Kpu+1q5n+24zU8CJhichlPikx1dxwSJU2ilUMz1EvIXUz9fEnNeDg== X-Received: by 10.223.141.200 with SMTP id o66mr3850045wrb.39.1520781465425; Sun, 11 Mar 2018 08:17:45 -0700 (PDT) Date: Sun, 11 Mar 2018 15:17:42 +0000 From: Stephane Chazelas To: bug-bash@gnu.org, Zsh hackers list , Joerg.Schilling@fokus.fraunhofer.de Subject: [minor] umask 400 causes here-{doc,string} failure Message-ID: <20180311151742.GB6450@chaz.gmail.com> Mail-Followup-To: bug-bash@gnu.org, Zsh hackers list , Joerg.Schilling@fokus.fraunhofer.de MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.24 (2015-08-30) Note: sent to bash, zsh and Schily Bourne shell dev mailing lists (not mksh as my email provider apparently doesn't play well with mirbsd.org's expensive greylisting, please feel free to forward there if you don't use gmail). That's from: https://unix.stackexchange.com/questions/429285/cannot-create-temp-file-for-here-document-permission-denied $ bash -c 'umask 400; cat <<< test' bash: cannot create temp file for here-document: Permission denied $ zsh -c 'umask 400; cat <<< test' zsh:1: can't create temp file for here document: permission denied $ bosh -c 'umask 400; cat << EOF test EOF' bosh: /tmp/sh193220: cannot open $ mksh -c 'umask 400; cat <<< test' mksh: can't open temporary file /tmp/sh933f2z.tmp: Permission denied Those shells use temporary files to store the content of the here-documents as the Bourne shell initially did, and open them in read-only mode to make it cat's stdin. When umask contains the 0400 bit, the file is created without read permission to the user, hence the error upon that second open(). (note that bosh also leaves the temp file behind in that case). I can think of several ways to address it: 1- do nothing and blame the user as the user explicitly asked for files to be unreadable (but then again, it's not obvious to the user that heredocs imply a temp file) 2- do like AT&T ksh/tcsh (or yash for big heredocs that don't fit in the pipe buffer) and open the file only once for both writing the content and making it the command's stdin (with a lseek() to beginning in between). That means the fd ends up being writable though I can't see it being a huge problem. (Yash actually gives the file 000 permissions here regardless of the umask with open("/tmp/yash-ECCFE6268", O_RDWR|O_CREAT|O_EXCL, 0), but see below about =(...) emulation) 3. do like dash/yash/rc/es and use a pipe instead of a temp file. That means having to fork a process to feed the data (or like yash fall back to a temp file for big heredocs). That also means the fd is no longer seekable The change could break some scripts for bash, as on Linux (where /dev/fd/n behaves differently from other *nices), we see some doing: cmd1 /dev/fd/3 3<<< "$(cmd2)" to emulate zsh's cmd1 =(cmd2) (command substitution using a temp file). (A 0400 umask also makes a =(...) file unreadable, but definitely here it's the user's problem). 4. Reset the umask temporarily to 077 before creating the temp file (and block trapped signals until it's restored). 2 would have my preference. -- Stephane