From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <zsh-workers-request@euclid.skiles.gatech.edu>
Received: (qmail 919 invoked from network); 12 Dec 1996 16:52:24 -0000
Received: from euclid.skiles.gatech.edu (list@130.207.146.50)
  by coral.primenet.com.au with SMTP; 12 Dec 1996 16:52:24 -0000
Received: (from list@localhost) by euclid.skiles.gatech.edu (8.7.3/8.7.3) id LAA06671; Thu, 12 Dec 1996 11:38:28 -0500 (EST)
Resent-Date: Thu, 12 Dec 1996 11:25:10 -0500 (EST)
Message-Id: <199612121625.LAA03602@redwood.skiles.gatech.edu>
To: zsh-users@math.gatech.edu
Subject: Re: newgrp 
In-reply-to: Your message of "Thu, 12 Dec 1996 15:18:09 +0100."
             <199612121418.PAA10636@bolyai.cs.elte.hu> 
Date: Thu, 12 Dec 1996 11:25:01 -0500
From: Richard Coleman <coleman@math.gatech.edu>
Resent-Message-ID: <"zUjJ43.0.KZ1.X73io"@euclid>
Resent-From: zsh-users@math.gatech.edu
X-Mailing-List: <zsh-users@math.gatech.edu> archive/latest/553
X-Loop: zsh-users@math.gatech.edu
X-Loop: zsh-workers@math.gatech.edu
Precedence: list
Resent-Sender: zsh-workers-request@math.gatech.edu

> > It is probably not the best solution, but I went around the lack of
> > newgrp command by writing the following script, and then asked my
> > administrator to change the owner to root and mode to 4755,
> > and finally add the alias newgrp='exec newgrp'.
> > At least it works !
> 
> Be careful with that.  Zsh was not designed to run setuid scripts although
> some attempt was made to make is somewhat secure.  I do hope that the
> script you wrote is secure but I cannot guarantee that zsh has no bugs that
> can be exploited to gain root privileges.  And I would not run ypcat and
> grep with 0 euid.  I would use this:

I'm very surprised your administrator did this.  This would make me too
nervous.

On many OS's, setuid scripts are not possible.  They are disabled at
the kernel level.  It's too easy to exploit race conditions in the
way many older kernels pass the pathname of the script to the interpreter.

I believe on some newer OS's (I believe Solaris is an example), the
kernel uses the /dev/fd filesystem to pass open file descriptors to the
interpreter, rather than passing the pathname of the script.  This removes
that race condition.

But no one has done a thorough check of the zsh source code to check how
secure it is with respect to setuid scripts.  My guess is that is can be
subverted with many of the standard tricks that have been used in the past
(buffer overrun problems in sprintf, etc...).

I would caution against using setuid zsh scripts at this point.

rc