Linux - ServerThis forum is for the discussion of Linux Software used in a server related context.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Dear all
At our university server, I patched together a script (lets call it connect.py) that kind of glues together a series of calls to different other programs (the first one is in Python2.X, the second is a binary so I use os.system('/path/to/program input.pot') to start it, and the last is in Python3.X). It kind of seems to work well now when working under my user account, where the script has the permissions to call the programs, because I installed them.
Now, when I want to start the connect script by pressing a submit button in an HTML form, naturally I start running into trouble. Now its no longer my user who is calling, but the server (Apache) with very limited rights. In the progress of writing the connect.py script, I had to do quite some environment adjustment so the various Python modules could be imported.
What is the easiest way to get the script started from an HTML form? I guess it would not be good practice to start extending the PATH variables of Apache, would it?
I can't tell you exactly what you need to do. I can tell you a couple of important things to remember when programming for the web:
First:
the script will run as the user that the apache server runs as. This is because it is the apache server that starts up the script when you press submit.
Second:
Even if you were able to login as the apache user, the interactive environment is likely different from that under apache. Look for a python function that acts like phpinfo(). This php function dumps out the php environment, so you can see exactly how things are configured.
Likely, you just need to find what changes are necessary to make your script run in a limited environment.
At our university server, I patched together a script (..). It kind of seems to work well now when working under my user account, where the script has the permissions to call the programs, because I installed them. Now, when I want to start the connect script by pressing a submit button in an HTML form, naturally I start running into trouble. Now its no longer my user who is calling, but the server (Apache) with very limited rights. In the progress of writing the connect.py script, I had to do quite some environment adjustment so the various Python modules could be imported. What is the easiest way to get the script started from an HTML form? I guess it would not be good practice to start extending the PATH variables of Apache, would it?
First of all do regard separation of privilege as a Good Thing (and not something Evil ;-p). And as far as "important things to remember when programming for the web" are concerned the more important issue is validating user input or rather: rejecting requests that (un)intentionally do not conform to specs instead of correcting them (bad) or assuming they're all good (even worse). Apache has a way to execute commands as a different UID than that of the web server user (suexec) and so has PHP (suPHP). For any other command you can use a custom CGI script which routes the request to your "connect.py" script through a 'sudo' CmndAlias.
Apache has a way to execute commands as a different UID than that of the web server user (suexec) and so has PHP (suPHP). For any other command you can use a custom CGI script which routes the request to your "connect.py" script through a 'sudo' CmndAlias.
Thanks for the hints so far guys.
@unSpawn: this sounds pretty much like something that would help me. I noticed what you said about precautions, and I'm definitely not ignoring them. At the moment though, I need to find a way of getting this running, that has the highest priority.
I was reading suexec is something people rather not tend to encourage using, as far as i remember correctly, its not in the default installation of apache.. could you maybe elaborate what it is that you mean with routing the script to sudo cmndalias? Does this mean Apache would temporarily switch its ID in order to execute the script?
I noticed what you said about precautions, and I'm definitely not ignoring them. At the moment though, I need to find a way of getting this running, that has the highest priority.
OK but adding security as an afterthought, by itself not that unusual in fast-paced development environments, is a Bad Thing.
Quote:
Originally Posted by mzh
I was reading suexec is something people rather not tend to encourage using, as far as i remember correctly, its not in the default installation of apache..
Note I only gave suexec as an example of the method. It being installed by default depends on the distribution. For me (running Centos) suexec comes standard with the httpd package. The problem with suexec is it requires root ownership and the setuid bit to be set. And yes, introducing setXid binaries is not a security best practice.
Quote:
Originally Posted by mzh
could you maybe elaborate what it is that you mean with routing the script to sudo cmndalias? Does this mean Apache would temporarily switch its ID in order to execute the script?
"Pushing a button" in a HTML page means passing a HTTP request to a CGI script. This CGI script executes (as the web server UID) a "/usr/bin/sudo /path/to/connect.py ${ANY_SANE_ARGS_HERE}" command. The "/path/to/connect.py ${ANY_SANE_ARGS_HERE}" corresponds with a "/path/to/connect.py" Cmnd_Alias in /etc/sudoers allowing the web server UID to run that command as your user.
thanks for the feedback, very helpful.
I worked around the whole issue now in a rather different way though, what i did is I installed the required program under the apache account, so it naturally has access to it.
What I am wondering now is to figure out how I can adjust the PATH variable of Apache, so it can run the program from any directory.
The httpd.conf looks something like this
Code:
SetEnv PATH $PATH:/var/www/programs/vmd
but it does not seem to include this path, i.e. the path /var/www/progams/vmd is not printed when I echo $PATH (as apache2 user).
What can I do?
When you login as the apache user, the http.conf file is not being read. This file is only read when apache is being started up.
that would also be fine, since i can just restart apache, but even after restarting it didn't seem to know about the new path. Still I would like to ask, what would be the correct way of adjusting the path variable. Did i miss something below?
@jason: I'll be seeing what i get out from that, thanks for the hint.
OK, i checked out the information from phpinfo(). What appears strange to me is that when I echo $PATH as www-data (in the shell), i get the following output:
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.