I am setting up a LAMP server in VirtualBox for personal development. This will be an Ubuntu Server 12.04 install, and I will be using Virtual Hosts for Drupal, Yii, and other small PHP apps. Ideally I'd like to avoid creating new Virtual Hosts in /var/www and instead opt for creating these under a public_html folder in my user's home directory.

Is there any benefit in creating another user (non-root) that will "host" these apps in their home directory, or will the root user created in the setup process suffice? I realise I'm being a bit pedantic by asking this, but its based on a recommendation I saw on another site (can't remember the URL) for setting up a LAMP server for personal development. I imagine this is only critical in a production environment. I'm thinking in terms of permissions, security, etc.

EDIT: Will I run into any issues using the root user to this end, or would I be safer creating a new non-root user?

EDIT2: Please don't down-vote this post! I would really like some clarity on this as I'm still walking the Linux learning path :)

  • By default, if you start apache as root it will switch to run as it's own special (non-priveleged) user after start up. This is to allow it to open a low number "privileged" port initially (normal http is 80), then run safely. There are other ways to deal with that, but two points: 1) this means it is okay to start apache as root, and 2) you may want to make the apache user (sometimes it is the "www" user) the owner of whatever files, or make the owner part of the apache/www group. – goldilocks May 6 '13 at 13:58

If this is going to accessible via the network, yes. In order for apache to access the public_html it's going to need some level of access to root's home directory (which could be catastrophic if they somehow found a way, via software vulnerability or unsafe configuration, to add something to root's .bash_profile or something).

Run as little as humanly possible under non-root accounts. Running stuff under non-root accounts isn't a "high security" precaution it's a very basic precaution on a par with not setting all your passwords to equal their respective usernames. You're still going to run into attacks even on home systems. My personal public web server and sshd is constantly under attack from outside sources (I never even had to tell anyone it was there). The IP's usually end up in South America or China. Even if you're behind a NAT and firewall, the system can still be potentially targeted.

If it's not accessible over the network, then the issue is largely moot, except that personal development should probably reflect the restrictions you're going to be running with in some sort of production scenario. Even if it's not going to ever be "production" it's still good to have the safety guards there so you don't accidentally develop your application so that it requires an unsafe configuration to run properly.


Another point: if you were to serve the VHost out of root's home directory, that would imply that you're logging in as root directly, which is another very basic security requirement. PermitRootLogin no in sshd_config should also be the effective configuration unless you have one hell of a reason to do otherwise.

  • Hi Joel. Yes it is going to be connected to the network, but I'm the only one who's going to be accessing it. – maGz May 6 '13 at 12:42
  • If it's on the network, other people are going to have some level of access. Don't run it as root. – Bratchley May 6 '13 at 12:43
  • But I share your thoughts regarding your last paragraph...which is why I asked the question in the first place. Even if I'm working as a single developer I want to try and mimic a live environment as much as possible. – maGz May 6 '13 at 12:43
  • So it does therefore make sense to do all of this under a non-root user? – maGz May 6 '13 at 12:48
  • Yeah, definitely. – Bratchley May 6 '13 at 12:48

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.