Running CGIs under my uid - going slowly insane.

Fri Feb 1 21:28:43 EST 2002

On Fri, 01 Feb 2002 19:36:18 +0000, Jonathan Hogg <jonathan at onegoodidea.com> wrote:

>On 1/2/2002 18:09, in article a3ell7$29bm$1 at nntp6.u.washington.edu, "Donn
>Cave" <donn at u.washington.edu> wrote:
>
>> Can I ask what operating system that experiment was performed on?
>[...]
>> That's true, but "executable" in this context usually means the binary,
>> i.e., python itself.  Years ago, some UNIX platforms introduced a hack
>> that made setuid effective for script files, but today that is universally
>> recognized to have been misguided.  That's why I'm curious about yours.
>
>Hah! How curious. Of course, you're right. I had forgotten this. Though it
>makes sense from the user's point of view - if being somewhat insecure
>(personally I prefer it in this world where the difference between compiled
>programs and scripts is blurred).
>
>To answer your question, I ran my test on Mac OS X. It seems OS X still
>retains the older semantics for script execution. Unsurprising since it is
>based on an old BSD.
>
>> Perl is subject to the same limitation, but has optional support for
>> setuid.  How can that be?  I'm no Perl whiz, but I assume you install
>> perl itself setuid root, and then it checks its input file for setuid
>> and either sets its ID accordingly or reverts to the invoker's ID.
>> This option is not the default and is rather discouraged as I recall it.
>
>Hmmmm... to return to the original question, in the absence of perl playing
>tricks with setuid, I would suggest a wrapper as being the best bet.
>
>You'll need to write a small program along the lines of:
>
>    #include <stdlib.h>
>
>    int main( int argc, char* argv[] )
>    {
>        char* args[] = { "python", "/my/script.py", NULL };
>        execv( "/usr/bin/python", args );
>    }
>
>Compile this, setuid it and then drop that into the cgi directory instead of
>the Python script. That should do the trick I think. If you can't compile
>stuff on the box or upload executables compiled elsewhere, then you're in
>trouble.
>
>Something to ask the providers is if they are willing to consider using
>Apache's suexec to invoke your CGIs. I have used that in the past to allow
>customers to run things as themselves.
>
They should really be happier doing that than allowing you to
setuid arbitrary binaries as above ;-)

    http://httpd.apache.org/docs/suexec.html

Rule 17 says maybe the above would work if you *don't* setuid it, but I don't think
you need it, unless maybe mod Python could otherwise get inbetween? I haven't set that
up myself.

I do have suEXEC enabled on a test linux box and just tried this:
--
#!/usr/bin/python
print """Content-type: text/html

<html><head><title>cgitest.py</title></head><body><pre>
"""
import os
print 'uid=%d,  gid=%d' % (os.getuid(),os.getgid())
print 'euid=%d,  egid=%d' % (os.geteuid(),os.getegid())
f=os.popen('id')
print f.readlines()
print """
</pre></body></html>
"""
--

Note that I just put it in cgi-bin and did chmod +x on it. Not setuid.
The browser shows this returned from the server for a non-suEXEC'd virtual
host:
--

uid=99,  gid=98
euid=99,  egid=98
['uid=99(nobody) gid=98(nobody) groups=98(nobody)\012']

and for a a virtual host n account with me as user:

uid=1000,  gid=100
euid=1000,  egid=100
['uid=1000(bokr) gid=100(users) groups=100(users),10(wheel)\012']

HTH,
Regards,
Bengt Richter