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
  • 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
    Commented Jun 19, 2013 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
    Commented Jun 19, 2013 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
    Commented Jun 19, 2013 at 3:39
  • I added "Note" to my question.
    – Radek
    Commented Jun 19, 2013 at 3:43
  • You've said what you want, and what you did. What exactly is your question? Is your +50 bounty going to the person who says "you're good"? Or is it not working and you need help?
    – bahamat
    Commented Jun 21, 2013 at 4:20

1 Answer 1


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.

  • 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
    Commented Jun 19, 2013 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
    Commented Jun 19, 2013 at 3:27

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .