Since I started programming LAMP apps I wanted to develop an admin control panel for my boxes. (For fun and educational purposes, otherwise I would use something already existing in the market)

But what always stopped me is I always heard exec() functions (the only way I know to achieve this) are the evil....you know: "don't use them", "it's bad coding", etc.

What I never hear is a safer alternative for that purpose, so my question is:

Is there any?

Isn't enough to run that app in a dedicated web server, with a password protected document root?

Well, that's my doubt.


I think the real risk is when you mix input from the user into one of these exec()'s. This is where most of the risk would come in, since you're allowing users to give you input that when mixed into the CLI can do dangerous things, such as insert semi-colons (;) into a text box and run additional commands after they've provided arguments.

So in general running commands in a readonly fashion shouldn't anymore dangerous than doing something else.

It's basically the same issue as with a SQL injection attack, which you might be more familiar with.

  • Thank you, Indeed I'm familiar with SQL Injection technique, but as I understand that doesn't apply here. since the code runs in a dedicated web server, under a password-protected directory, which is only accesed by the administrator...am I missing something? – Kev Oct 12 '13 at 19:23
  • Arguments that are passed into a text box and then included as arguments to a command that runs under exec() would be the attack vector. Running the server under a chroot'd directory would be one way to limit your exposure too. – slm Oct 12 '13 at 19:30
  • mmm I still don't get it, how will an attacker manage to inject the malicious code when the document root is password protected? – Kev Oct 12 '13 at 19:39
  • @Kev - yeah, the warning I'm talking about would be if it wasn't protected by a password, or if they gained access. One other thing to keep in mind, with the password guarding document root, there is not counter measures, typically, so a user could sit there and run a script pumping passwords into that box until they theoretically guessed it. Small risk but one other thing to keep in the back of your mind when exposing this type of surface to the outside. – slm Oct 12 '13 at 19:42
  • Thank you, of course I could add some aditional measures like limit the access to determined IP address. Didn't checked yet but i'm sure the web server can also limite the amount of login attemps an user can have...do you think I can get a relatively safe envirnment under this parameters? – Kev Oct 12 '13 at 19:55

As far as I know (and I am not a programmer really so take it with a pinch of salt), exec() calls are not evil at all. It is just that they fork a new process and have a high overhead since you are calling a system function. Generally, people suggest you do things internally in whatever program/script you're writing and avoid external calls like exec().

However, if your objective is to execute commands on the system, there is no way of doing it without such a call. Of course, there are security risks, allowing random users to execute arbitrary commands on your server is inviting trouble. However, if the access to this server is severely restricted, you should be able to do it safely.

Anyway, main conclusion, exec() functions are not inherently bad, they simply tend to be less efficient than doing something internally.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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