Commands fails when starting bash from perl but not when starting from command line, permission issues

Question

I have created a bash script that should be started from a perl script. When I run the bash directly from the terminal it works like a charm. But when trying to run the bash from my PERL-script I get a lot of permission errors.

Activities I do is creating files/directories/restaring apps/etc. How should I configure in order for the perl-script to be able to execute the bash without permission errors.

I execute the command from perl like this:

system($file, $arg);

Example of commands in bash:

exec 1>$1.log
exec 2>$1_error.log

mkdir /opt/$1

Example from error log for commands above:

[Wed Aug 10 18:17:17 2011] [error] [client 192.168.1.100] /opt/otrsadm/newinstance.sh: line 3: comp.log: Permission denied
[Wed Aug 10 18:17:17 2011] [error] [client 192.168.1.100] /opt/otrsadm/newinstance.sh: line 4: comp_error.log: Permission denied
[Wed Aug 10 18:17:17 2011] [error] [client 192.168.1.100] mkdir: 
[Wed Aug 10 18:17:17 2011] [error] [client 192.168.1.100] cannot create directory `/opt/comp'
[Wed Aug 10 18:17:17 2011] [error] [client 192.168.1.100] : Permission denied
[Wed Aug 10 18:17:17 2011] [error] [client 192.168.1.100]

What I am doing is creating a totally new instance of an application on an Apache. That means, the bash is creating necessary dir, copying the app to that dir, creating a new database and loading a template-dump, copying the application-specific config files for apache and exchanging some strings in that file, etc.

I am totally new doing this kind of activities so any possible help is highly appreciated.

Answer 1

I'm guessing your current working directory is wrong in your perl script - you're trying to execute your bash commands in a directory where you don't have permissions to create directories.

Answer 2

You script is running under the same permissions as the Apache process. Good security practices require that your web server have as limited permissions as possible to change files that might themselves be run by the web server.

Since this sounds like exactly what you want to do the trick is to loosen up the permissions as little as possible to get the result you want.

My recommendation is to look into the program sudo . It can run programs as more privileged users, and provides some reasonable access controls. The basic idea would be to create a script that is owned, and only writable by the root user. Then allow the apache user (or httpd, or what ever your system calls the user running Apache) to execute that script through sudo as a user with the permission to write to /opt . If you can get away with executing the script as a user less privileged than root that is also good.

Assuming you have good error checking in your script and follow all good security practices you will be reasonably secure.

All that said, strongly consider paying an experienced, security minded developer to assist you with setting this up. Setting up a system like this requires a different mindset towords security, and that's something you can't get from an answer on SO. Otherwise you might have to explain to your boss how a 13 year old kid from some random country deleted all your companies data, or worse released it on BitTorrent.

Answer 3

In your log, you have an error message split across lines:

mkdir: 
cannot create directory `/opt/comp'
: Permission denied

Is it possible that you Perl script is invoking you bash script with an argument that contains a newline? (Though that wouldn't explain why the "mkdir:" is on a line by itself.)

Do you have write permission on /opt ?

Answer 4

change the permission of opt directory to 777 (read/write/execute by everyone)

chmod 777 /opt/

I think this might solve your problem.