Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I'm attempting to understand some concepts surrounding security and environment variables for a web application running under Apache on Ubuntu 10.04 Server.

I have a few applications that I would like to run as a user that has no shell or password (I understand that this is a good idea, but I'm no expert). One of the applications is a web app that is started via a system init script, the others are utilities started on an ad-hoc basis from the commandline via sudo with the -u switch.

Each application needs access to the same set of environment variables. I can modify the script that starts each application, and set the environment variables there, but I would prefer it if the environment variables were somehow set for the user under which the application is run.

My questions are:

Is that possible to set 'per user' environment variables for a user that has no shell? I've read "Setting environment variables for a service without a login shell on Debian", but the given solution is essentially the same as modifying each of my application scripts.

If I cannot set the environment variables per user, what are the security risks associated with giving the user a shell?

What, if any, are the alternatives or recommendations for this presumably common situation?

share|improve this question

2 Answers 2

up vote 2 down vote accepted

Using a configuration file, and adding the variables through the application's startup script is really the correct way to handle this. If you need to provide certain environment variables to non-shell scripts or binaries (like perl, python, or java), you can call them with a shell wrapper, provide the needed variables, and then exec the real script.

If your applications are started by some sort of script, it must be started by calling a shell (the shebang at the top of the file), even if the user has no login shell. You could therefor modify the environment variables through the shell's rc files just as you would for regular users. I believe you would still need to insert the BASH_ENV variable to get the rc files to trigger, since you're calling the script non-interactively.

I'm going to highly recommend that you use the former method, and create some sort of configuration for the applications. It will be much easier to manage in the long run.

share|improve this answer
    
Thanks for he answer - please could you expand a little on your suggested solution of creating a configuration for the applications? They are all Perl applications, one is the main web app running under Apache, and the others are utility scripts, some of which can be run as daemons. Are you suggesting that I modify the Perl scripts, as I have done already for the web app? –  Mike Jun 2 '11 at 15:32
1  
@Mike: environment is controlled by the caller. If you're calling a perl script yourself (even with sudo), it's up to you to provide the correct environment variables. –  JimB Jun 2 '11 at 16:06
    
Thanks for the update. –  Mike Jun 3 '11 at 6:59

Environment variables are an aspect of the shell. So I'm fairly certain that no shell == no environment variables.

As a general rule, I would not give service accounts login privileges. The short answer is that it's just something else to worry about. It's just one more potential intrusion point.

Personally, this is where I would use a config file (/etc/myapp.conf). You can just have the init script that starts the web app, source the file and have your other apps look in a default location or take arguments on the command line.

share|improve this answer
3  
"Environment variables are an aspect of the shell. So I'm fairly certain that no shell == no environment variables." !? This is incorrect. Every process has an "environment", and associated variables. Even the mother of all processes, 1 (init), has environment variables declared, and it's definitely not a shell. –  JimB Jun 2 '11 at 14:22
    
Duh. My bad. Thanks correcting that bit of misinformation. –  animalormachine Jun 12 '11 at 15:05

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.