Want to protect your cyber security and still get fast solutions? Ask a secure question today.Go Premium


How to run a CGI script as root with password prompt

Posted on 2003-11-07
Medium Priority
Last Modified: 2012-06-27
I am looking for a secure way to have a Perl script to run as root under Apache.  The user would be prompted for a password and this password would be verified.  Naturally I would use SSL on the script so that the password does not get passed in the clear.  This is for a commercial product so it cannot be too dependant on system specific configurations.

Things that I have looked into are:

- SUExec (does not support root)

- Using system(SU) - Generally SU is not available to other than root:wheel and not the ID apache runs under.

- suidperl - I understand that this is not recommended and is not always available.

One idea I had was to create a script that would invoke SUDO on a shell script.  The script would verify the root password against etc/password and then proceed to do what it needs to do.  The SUDO script would be set up to be run by anyone and not require a password prompt since the script itself would verify the password from the environment variable for the edit field on the form that invoked the script.

Am I heading down the right path or is there some other more standard way to do this?

Question by:elsamman

Expert Comment

ID: 9701655

Write a Perl program to be the Authenticator, so If authenticated, then execute sudo application B. Write tracking functions to log all calls to application B, maybe even put time restrictions, and if too many invalid tries from a particular IP, etc then short circuit them to the bit bucket or something of the sort.

Author Comment

ID: 9701734
I don't see how that is secure.  If "Application B" which does the work that requires root does not do the authentication then anyone could execute it and bypass the Perl authenticator.  Am I missing something?

Expert Comment

ID: 9702006
You make Application B inaccessable via the internet. Read the Env vars to see if someone attempted a POST or a GET and Deny access is one method.

Another method is to create a secure token that Application B will not work unless it recieves it from the first application.

Place it in a dir that cannot be accessed directly

Deny access to that file directly via conf directives

The method for securing the second application should be a trivial matter.

Modern healthcare requires a modern cloud. View this brief video to understand how the Concerto Cloud for Healthcare can help your organization.


Expert Comment

ID: 9702010
Using Sudo you have one form of tracking anyways via the sudo logs

Author Comment

ID: 9702093
This might be OK in a really secure environment.  I am dealing with a shared hosting environment where anyone could write a piece of Perl code to execute "Application B".  All CGI applications run under the same user (nobody).  I don't really like passing a token since that is almost like embedding a password in a file which as far as I am concerned should never be done.  Anyone with read access to the programs can find the token/password.  If I am going to pass a token I might as well just pass along the password I collect from the user and let application b authenticate.

Expert Comment

ID: 9702409
ah, usually a shared access environment you don't really want anyone running a root application anyways. So yes that would require a different approach.

The setup wouldn't make me feel that safe with any of those approaches.

I think you would be heading down the correct path with your original idea. Just use the PAM library or something like that to access the password data to do the verfication.

Looks like you had the right idea all along. :)

Expert Comment

ID: 9705296
what web server are you using?

if you are using Apache, you can use a .htaccess file to restrict access to the Perl script with username and password. and then put the Perl script in an SHTTPD directory so that all data going through are secure. this way only authenticated users may access the Perl script and everything coming in and out of the script are secured.
LVL 51

Accepted Solution

ahoffmann earned 1500 total points
ID: 9710261
as you already know: suEXEC does not support root.
Apache is safe web server, so only running apache as root itself, which is not recomended, gives you the posibility to run a CGI as root.

Another aproach would be:
  echo 'asroot:x:0:0:alias user for root:/asroot:/usr/bin/tcsh' >>/etc/passwd
then setup apache with suEXEC and allow user asroot to run your CGI (donÄt orget chmod, chown etc.).

Keep in mind that this opens your system for root access.
Also some *nix systems do not support this.
I's not suggest to do it, it's up to you.

Author Comment

ID: 9833375
Actually the solution that I am going with is the usual one.  At the end of every thread on this topic the advice of most sages is "use the cron Luke".  In other words find a way not to have to run your cgi script as root.  Write a script that leaves bread crumbs for a cron job to pick up and do the deed.

The most secure way I have found to do this is leave an indicator of what I want done in a mySQL database row.  I use the mysql user password to authenticate.  A cron job comes along every 5 minutes or so and does the deed.  I

 None the less I did not know about the alias trick and am very greatful to have that in my arsenal for future use.


Featured Post

Who's Defending Your Organization from Threats?

Protecting against advanced threats requires an IT dream team – a well-oiled machine of people and solutions working together to defend your organization. Download our resource kit today to learn more about the tools you need to build you IT Dream Team!

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

If you are like me and like multiple layers of protection, read on!
Experts Exchange expands question security options for members.
Nobody understands Phishing better than an anti-spam company. That’s why we are providing Phishing Awareness Training to our customers. According to a report by Verizon, only 3% of targeted users report malicious emails to management. With compan…
With Secure Portal Encryption, the recipient is sent a link to their email address directing them to the email laundry delivery page. From there, the recipient will be required to enter a user name and password to enter the page. Once the recipient …

581 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question