How to run a CGI script as root with password prompt

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?

Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.


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.
elsammanAuthor Commented:
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?
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.
The 7 Worst Nightmares of a Sysadmin

Fear not! To defend your business’ IT systems we’re going to shine a light on the seven most sinister terrors that haunt sysadmins. That way you can be sure there’s nothing in your stack waiting to go bump in the night.

Using Sudo you have one form of tracking anyways via the sudo logs
elsammanAuthor Commented:
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.
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. :)
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.
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.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
elsammanAuthor Commented:
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.

It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.