CGI and root privilege

CyberGod,

":.. how can I be root when I run a cgi script  via web ? ."


The solution for this would be to running the script with elevated privilege level.

You can run a script in suid mode. What this means is that instead of a script running as the user that
invokes it it will run as the user that owns it.

Changing a script's permissions to indicate it should run suid involves using a less commonly known
feature of the "chmod" command. A good unix reference will explain fully, but basically scripts that
you want to run suid will be set up with the command "chmod 4711 scriptname" - the leading '4' indicates
suid execution is desired. Setting files suid is a restricted operation, and can not be accomplished
via FTP

The meaning of suid is hard to explain unless you already have a good understanding of Unix file permissions-
but here's a quick example that may help:
Assume you have a script, it will be owned by you, and by default will be in group clients. Normally
(since it's a CGI script) it will be set to mode 755 (which is really short for 0755) - it will execute
with the permissions of whoever invokes it. That means if the script tries to read a file with mode
600 (user read/write only) the script will not be able to open the file, so an error will occurr.  

 If you change its permissions to 4711, it will always run with your privilege level, regardless of
which user invokes it. If it tries to read that same file, it will work fine.  

   Running suid scripts allows much more flexibility in the operations your scripts can perform, but
it comes with a price. Since you're running these scripts with elevated privileges, there are some changes
that will need to be made depending upon the exact implementation. You also need to make sure the script
code can not be subverted to do more than you planned to allow.

Perl also treats suid scripts specially. You will have to do one of two things to successfully run suid
perl scripts. The easiest is to use the -U switch (#!/usr/bin/perl -U) which says essentially "Hey Perl-
I know what I'm doing here, so don't warn me about tainted variables and things like that." The other
is to go through the laborious process of "untainting" every potentially unsecure variable you use in
the script. This is a big pain, but the process will teach you a lot about perl.


Hope that helps.

CyberGod,

You have the following 6 questions open for some time now.

Please take some time to close these questions.

EE userid CyberGod
Total questions asked 17 (100%)
Open questions 6
       

Topic Area              URL              Date              
CGI   https://www.experts-exchange.com/jsp/qShow.jsp?ta=cgi&qid=20260374   01/28/02  
Linux Administration   https://www.experts-exchange.com/jsp/qShow.jsp?ta=linuxadmin&qid=20192196   10/08/01  
Linux Networking   https://www.experts-exchange.com/jsp/qShow.jsp?ta=linuxnet&qid=20145315   07/03/01  
Linux Networking   https://www.experts-exchange.com/jsp/qShow.jsp?ta=linuxnet&qid=20145317   07/03/01  
Linux Networking   https://www.experts-exchange.com/jsp/qShow.jsp?ta=linuxnet&qid=20177015   08/31/01  
Unix Networking   https://www.experts-exchange.com/jsp/qShow.jsp?ta=unixnet&qid=11836298   11/12/00  

Your help in closing these questions will be highly appreciated.

Thanks,

maneshr

(NOT a moderator at EE)

CyberGod,

The above comment should have read ...

You have the following 5 questions open for some time now.

i apologize for the incorrect numbers.

manshir, mode 4711 is not sufficient for scripts, must be 4755 instead.
Also when explaining suid behaviour, it might be better to use the terms "user" and "owner" instead of simply "you". Means that a file is owned for example by user1, but executed by user2, then the program (or script) uses (inherits) the permissions of its owner (user1 in this example) even if executed by user2.

Running perl CGIs with -U instead of -T is high risk, hope that people are used to the security difference ...

ahoffmann,

Thank you for your comments.

i want to especially underline your following statement.

"..Running perl CGIs with -U instead of -T is high risk, hope that people are used to the security difference ..."

Hopefully, with all this info CyberGod is now in a better position to make an informed decision.

.. and gets used to my pedantic security comments :-)

done?

Well when I run a cgi script via web I am user nobody and the script runs iptables which has to be root, so even if I suid the cgi script I still do not have a persmission to run it.

Thats an interesting idea but time is critical for me. Thanks anyway !

CyberGod,

Have you tried Webmin (http://www.webmin.com/webmin/).  There are room for custom made modules that you could write.  I guess that ease up some part of building the infstracture (since webmin already took care), just concentrate on revising you code to adopt to those of webmin modules.

just a recommendation.

I have Webmin , but I need to do it by my self

Not sure what you meant by "time is critical". A cron can run every minute. Or you can create a root script which runs continually and watches which would actually be more immeadiate than a single cgi doing it. In fact it would be so fast that we would have to talk about "go files" so that you dont process the request while its still being written out.

I think everyone pretty much covered all options. The only thing more extreme that I can think of would be wide open such as making "nobody' equal to root.

Gandalf  Parker

Not sure what you meant by "time is critical". A cron can run every minute. Or you can create a root script which runs continually and watches which would actually be more immeadiate than a single cgi doing it. In fact it would be so fast that we would have to talk about "go files" so that you dont process the request while its still being written out.

I think everyone pretty much covered all options. The only thing more extreme that I can think of would be wide open such as making "nobody' equal to root.

Gandalf  Parker