Re: setgid-wrapper

[Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de>]

"Grzegorz B. Prokopski" <gadek@debian.org> writes:

> On (19/05/04 15:54), Goswin von Brederlow wrote:
>> Jeroen van Wolffelaar <jeroen@wolffelaar.nl> writes:
>> 
>> > On Wed, May 19, 2004 at 07:53:46AM -0400, James Damour wrote:
>> >> On Tue, 2004-05-18 at 09:03, Steven Augart wrote:
>> >> > As you probably know, when a shell sees that it is running a setuid or 
>> >> > setgid shell script, it detects this because the euid and ruid or egid 
>> >> > and rgid are different.  It "fixes" this by setting the euid to be the 
>> >> > same as the ruid, and/or egid the same as the rgid, effectively 
>> >> > turning off the setuid/setgid bit.
>> >
>> > Huh? This is wrong. It is the kernel who refuses to set the UID or GID
>> > on execution of setuid/gid shell scripts.
>> >
>> > Where did you read that?
>> 
>> Could it be you mean bash droping the setuid/setgid bits when it is
>> set setuid/setgid? Thats a bash speciality preventing hackers to
>> setuid/gid bash as so many rootkits have done in the past.
>
> No.  Bash is not dropping any of its priviledges.  If you want to give
> all users root access just set suid on /bin/bash ;-))

man bash:

       If the shell is started with the effective user (group) id not equal to
       the real user (group) id, and the -p option is not supplied, no startup
       files are read, shell functions are not inherited from the environment,
       the SHELLOPTS variable, if it appears in the environment,  is  ignored,
       and the effective user id is set to the real user id.  If the -p option
       is supplied at invocation, the startup behavior is the  same,  but  the
       effective user id is not reset.

MfG
        Goswin