Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I want to confirm that my thoughts are correct as this is about security matter.

We have web based application which is using db2 database. db2 runs under the db2inst1 user.

Now we want users of the web application to be able to restore db2 backup images into a database that we call playschool. Using this playschool they "play around" and make no harm to the production database. To do so PHP script db2restore needs to be executed via PHP function exec().

Is it secure enough to make sure that no one can misuse and run db2 commands as PHP user if:

  • we add this line to /etc/sudoers

    php ALL=(db2inst1) NOPASSWD: /opt/eduserver/bin/db2restore
  • and then run inside PHP db2restore script this command

    exec('sudo -u db2inst1 /opt/eduserver/bin/db2restore');


  • that not all end users will have access to run db2restore via web interface, only admin group where they 'should' know what they are doing.
  • no end user had access to command line of the server.
  • db2restore is not accessible via web server
share|improve this question
@slm: thank you for the clean up :-) – Radek Jun 19 '13 at 3:19
Should be OK, but just a word of warning: As this restoration program/script runs with no real supervision, it might be used to lock up the server by calling that function at a very fast rate (i.e. running the PHP file over and over.) You can scold your customers for doing that, but in case there is a way to fake user accounts or meander to that script from "outside", I'd give it a bit more scrutiny. – polemon Jun 19 '13 at 3:30
Good point actually as the process of database restore slows down the server. But for the user to be able to restore db they will have to be a in special security group (within the web application) . So not everyone can execute restore. – Radek Jun 19 '13 at 3:33
OK, your initial explanation led me to think that any customer can actually restore the db from the web application. And the user stuff is more of the kind, that someone might find a way to access this script while not being a user at all of the webpage, If you know what I mean. There is a word for that, that I keep forgetting. When lower tier users and "guests" gain access to administrative components, etc. – polemon Jun 19 '13 at 3:39
I added "Note" to my question. – Radek Jun 19 '13 at 3:43

I don't see anything inherently wrong with doing it this way. The only thing that pops out is that someone could play games with the contents of db2restore if that file were owned by db2inst1 and not root, for example.

I'm also going to assume that this playschool database is not on the production system. If it is then this becomes a bad idea, if he developers are logging into the production database.

In general when giving out access to a database I've always historically created user accounts within the database and then given out specific capabilities (add, drop, etc.) to that particular user account.

share|improve this answer
Playschool db is for end user to try whatever they want and also try new version of the code. Let's assume that end users don't have ssh access to the application server ( web server + db2 server ) – Radek Jun 19 '13 at 3:19
+1 for the individual user accounts in the database. It is usually a better Idea to have that managed by a script that has access to the db. – polemon Jun 19 '13 at 3:27

Your Answer


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.