Re: newgrp

Re: newgrp

[Peter Stephenson]

> Wether with the above function, or with the alias proposed in the FAQ,
> I always finally receive the message "zsh: newgrp not found",
> since there is no newgrp command available.

aha --- most systems have an external command newgrp available which
seems to be missing there.  zsh does have some mechanism for changing
the group by altering $GID, but the way it's set up it's only usable by
the superuser, as far as I can tell.

This seems to be a fatal flaw --- anybody else any suggestions?

(P.S.: note new spelling of Deutsches and Elektronen.  Sorry.)

-- 
Peter Stephenson <pws@ifh.de>       Tel: +49 33762 77366
WWW:  http://www.ifh.de/~pws/       Fax: +49 33762 77413
Deutsches Elektronen-Synchrotron --- Institut fuer Hochenergiephysik Zeuthen
DESY-IfH, 15735 Zeuthen, Germany.

Re: newgrp

[Zoltan Hidvegi]

Peter Stephenson wrote:
> > Wether with the above function, or with the alias proposed in the FAQ,
> > I always finally receive the message "zsh: newgrp not found",
> > since there is no newgrp command available.
> 
> aha --- most systems have an external command newgrp available which
> seems to be missing there.  zsh does have some mechanism for changing
> the group by altering $GID, but the way it's set up it's only usable by
> the superuser, as far as I can tell.

That's because on Unix systems superuser privileges are required to change
the primary group id.  There is nothing in zsh which would prevent changing
the GID parameter.  If it fails it fails because the OS refused change it.
Of course some trickery with chgrp and setgid might also help but on secure
systems normal users have no write access to suid mounted filesystems.
Also secure systems does not use HP, or if ther use, they definitely do not
keep suid newgrp since a root exploit was posted recently to bugtraq using
HP's newgrp (where you can find one or two HP root exploits every week so
if you subscribe it will not be difficult to install the missing newgrp on
your machine).

Zoltan

Re: newgrp

[David Chamont]

> 
> That's because on Unix systems superuser privileges are required to change
> the primary group id.  There is nothing in zsh which would prevent changing
> the GID parameter.  If it fails it fails because the OS refused change it.
> Of course some trickery with chgrp and setgid might also help but on secure
> systems normal users have no write access to suid mounted filesystems.
> Also secure systems does not use HP, or if ther use, they definitely do not
> keep suid newgrp since a root exploit was posted recently to bugtraq using
> HP's newgrp (where you can find one or two HP root exploits every week so
> if you subscribe it will not be difficult to install the missing newgrp on
> your machine).
> 

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 !

          --------------------------------------------
          #!/usr/local/bin/zsh
          
          accord=non
          for g in `groups` ; do
            if [[ $g = "$1" ]] ; then
              group=`ypcat group | grep "^${1}:"`
              GID=${${group%:*}##*:}
            fi
          done
          
          EUID=$UID
          exec zsh
          --------------------------------------------

Thanks to the people who respond to my question and helped
me find out this solution.

==========================================================================
David Chamont - LPNHE                             
chamont@polhp3.in2p3.fr
Ecole Polytechnique                                        
01.69.33.44.04
91128 Palaiseau - France            
http://polhp5.in2p3.fr:8000/~chamont/

Re: newgrp

[Zoltan Hidvegi]

David Chamont wrote:
> 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:

>           --------------------------------------------
>           #!/usr/local/bin/zsh

            EUID=UID

>           
>           accord=non
>           for g in `groups` ; do
>             if [[ $g = "$1" ]] ; then
>               group=`ypcat group | grep "^${1}:"`
                EUID=0
>               GID=${${group%:*}##*:}
                break
>             fi
>           done
>           
>           EUID=$UID
            UID=UID
>           exec zsh
>           --------------------------------------------

Zoltan

Re: newgrp

[Richard Coleman]

> > 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

newgrp

[David Chamont]

Hi,

I am working in a cluster of HP Unix workstations.
We make a big use of Unix groups, and the lack of the
newgrp command is a real obstacle.

The FAQ trick does not work (alias newgrp="exec newgrp"),
perhaps because I put zsh as my login shell.

Any suggestion ?

thanks.
David.

==========================================================================
David Chamont - LPNHE                             
chamont@polhp3.in2p3.fr
Ecole Polytechnique                                        
01.69.33.44.04
91128 Palaiseau - France            
http://polhp5.in2p3.fr:8000/~chamont/

Re: newgrp

[Peter Stephenson]

David Chamont wrote:
> Hi,
> 
> I am working in a cluster of HP Unix workstations.
> We make a big use of Unix groups, and the lack of the
> newgrp command is a real obstacle.
> 
> The FAQ trick does not work (alias newgrp="exec newgrp"),
> perhaps because I put zsh as my login shell.

I don't quite understand the problem.  Are you saying you need the new
shell to be a login shell if the old one was?  You could try something
like this:

newgrp () {
  local args;
  [[ -o login ]] && args=-
  exec =newgrp $args $*
}

If that's what you want I'll change the FAQ.

(Just in case it helps:  if you have changed $SHELL, it looks like
newgrp won't honour it, it will go back to the passwd entry.)

Bonne chance.
-- 
Peter Stephenson <pws@ifh.de>       Tel: +49 33762 77366
WWW:  http://www.ifh.de/~pws/       Fax: +49 33762 77413
Deutches Electronen-Synchrotron --- Institut fuer Hochenergiephysik Zeuthen
DESY-IfH, 15735 Zeuthen, Germany.