[Nottingham] suid / sgid file params puzzle ... or a bug?

[Mark O'Shea]

See below for comments.

On Sat, 29 May 2004, Martin wrote:

> OK, so is this too obscure for comment?
>
> Or should both work as I expected and this is indeed a kernel 2.6.3 bug?
>
> (And yes, this is top posting (;-P))
>
> Martin
> Martin wrote:
> > Folks,
> >
> > I'm trying to use the set user id and set group id bits, but this
> > doesn't work as I expected...
> >
> >
> > A bash script run as root calls a program that has the suid and sgid
> > bits set. Eg:
> >
> > #!/bin/bash
> > /home/user1/FAH4Console-Linux.exe &
> >
> > And ls -l gives:
> >
> > -rwsr-s---  1 user1 user1 241K Mar 23 21:16 FAH4Console-Linux.exe*
> >
> > The FAH4Console-Linux.exe runs as user1 ok. However, other programs that
> > are then called up by FAH4Console-Linux.exe run as root!
> >
> > (The FAH4Console-Linux.exe is a binary prog.)
> >
> > One way round this is to use:
> > su --command=$fah4 user1
> >
> > (where $fah4 is /home/user1/FAH4Console-Linux.exe)
> >
> > Then, all the programs run as user1 as expected.
> >
> >
> > So, what's happening?
> > What's the difference between the two??
> >
> >
> > Bemused,
> > Martin
> >
> >
Well this looks like the behaviour that you would expect.  When you
execute a file with the suid or sgid bits set it doesn't actually change
your real uid or gid while you execute the file, just the effective u/gid.
If that process then executes another file the new process won't inherit
the effective u/gid, only the real one (okay, the exception AFAIK is if it
forks only).

Using su on the otherhand changes your real uid or gid, so anything
executed after that will inherit the real u/gid that you requested.

So it's not a bug but a security feature.  What I would probably do is
look at why this bash script is running as root in the first place,as if
it was found that it is necessary then use su to change your ruid to that
of the unprivileged user to run it.

Regards,
-- 
Mark O'Shea