Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!ucbvax!NUSVM.BITNET!GBOPOLY1
From: GBOPOLY1@NUSVM.BITNET (fclim)
Newsgroups: comp.sys.apollo
Subject: Re: su
Message-ID: <8906290940.AA13511@umix.cc.umich.edu>
Date: 29 Jun 89 09:40:55 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 32
X-Unparsable-Date: Thu, 29 Jun 89 16:59:10 SST

In article <5892@joshua.athertn.Atherton.COM> joshua%athertn%pyramid%oliveb
.uucp@apple.com  (Flame Bait) writes

>In article <366@quintro.UUCP> kts@quintro.UUCP (Kenneth T. Smelcer) writes:
>>At SR10.1, you must belong to group "wheel" in order to 'su' to root.
>>This is a convention direct from Berkeley.  Does anyone know of a way
>>to change this?
>
>As for fixing it, try doing something tricky with shell scripts.  Have
>a shell script which is setuid and owned by wheel; use it to call the "real"
>su.  This will do bad things for security, but that's life.  What else
>is group wheel used for?  If nothing, just add everyone to it.  Look for
>public domain versions of su.

Ken sez that wheel is a group id and not a user id.  In this case,
the shell script must have several bits set.  Firstly, it needs to
be owned by root (I don't think wheel owning it will work).  Then
it must have its group id set to wheel.  Finally the setuid and setgid
permission modes must be set.  ie
       % /etc/chown root shell-script
       % /bin/chgrp wheel shell-script
       % chmod 6755 shell-script
       % ls -l shell-script
       -rwsr-sr-x ? root ....
       % ls -lg shell-script
       -rwsr-sr-x ? wheel ....

fclim          --- gbopoly1 % nusvm.bitnet @ cunyvm.cuny.edu
computer centre
singapore polytechnic
dover road
singapore 0513.