From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18863 invoked by alias); 13 May 2015 15:48:36 -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: 35108 Received: (qmail 4796 invoked from network); 13 May 2015 15:48:33 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.2 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:content-type; bh=A8zECPjxxdrVqdp3LFc9i71JgSA5aI3q9xk1opUlL8o=; b=PM28Mfg9+ZVttyoVluyHZjNIgmaNW2jFEUlEL2xfFL9IYt0otR997JU8ALYMMb4Rhw bfXHGhiSY4fOGjp5svztkShbVxX7mTof12hsfxmDBN8qtgDm7OgPlvSkSF0bgMmyts2B VHoH7h9YsxYqQt9Wi8eUPTewhGM2M36DzarhNl0SvtJG04gkrXyoB04meTSSjQ9IEyJ0 13SMz1XJpmAESTuX5sNUmRcS7low23WW37fWTwygKnUcuHmFWt0HLcSxdVAWJ0gD7+gp ThSeOD8s0Tp/cJlhoqawpC2IDwOR1pfNHnGNj0qnB8RBuzaVU7D0Z3h6dMZV+xXidY/P 0/Aw== X-Gm-Message-State: ALoCoQnloYSoghkMrCbejPBJievuqHV2S+qHPoP2QkGrbYSqoRlLK+zStrgtH6WWKTRDz9lQYNXl X-Received: by 10.202.74.71 with SMTP id x68mr15981577oia.93.1431532111685; Wed, 13 May 2015 08:48:31 -0700 (PDT) From: Bart Schaefer Message-Id: <150513084827.ZM15168@torch.brasslantern.com> Date: Wed, 13 May 2015 08:48:27 -0700 In-Reply-To: <20150513093945.749366aa@pwslap01u.europe.root.pri> Comments: In reply to Peter Stephenson "Re: Failure of "typeset" and exit status" (May 13, 9:39am) References: <150511194320.ZM12928@torch.brasslantern.com> <150512215919.ZM13985@torch.brasslantern.com> <20150513093945.749366aa@pwslap01u.europe.root.pri> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh-workers@zsh.org Subject: Re: Failure of "typeset" and exit status MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On May 13, 9:39am, Peter Stephenson wrote: } } So you're worried about this } } % (){ local UID && print Still going; } } (anon): failed to change user ID: operation not permitted } Still going } } Here's one possibility: in that case, there's no explicit set to UID so } maybe we should make it local and leave it alone --- I'm not sure how to } detect a case like this, though. It's weird that unset produces no error, but local does so even if UID was previously unset: torch% unset UID torch% (){ local UID } (anon): failed to change user ID: operation not permitted torch% (){ unset UID } torch% } Then if you explicitly assign to it } (in our out of typeset) and *that* fails, return status 1. I looked at that first, but there is a whole chain of void-returning functions down from bin_typeset() to the setuid() call that triggers the warning. Propagating a non-fatal error would require a lot of rejiggering. It appears that the real problem is that UID is typed as an integer, so "local UID" implicitly assigns zero. That means that for a process that IS allowed to change UID, merely declaring it local causes that process to assume root privilege. That's clearly both wrong and a potential security issue. -- Barton E. Schaefer