Is it a bad idea to grant shell access to the user account destined to be running Apache/Nginx?

I ask because, the Guvnr, in his VPS Bible series, sets up a new user with visudo'd

guvnr  ALL=(ALL) ALL

privileges, and then sets up an Nginx server with that user.

Whereas the authors of Nginx HTTP Server recommend that you not grant shell access to the user running Nginx.

You could always remove guvnr's shell access, but then, how would you administer your websites?

edit: @Bart Silverstrim - Here's how the guvnr installs Nginx:

  • (logged in as user guvnr)
  • sudo install nginx dependencies
  • user wget nginx source files
  • user ./configure --sbin-path=/usr/local/sbin --with-http_ssl_module
  • user make
  • sudo make install

So perhaps Nginx is being installed to root here?

Is this an ok practice if root login is disabled in /etc/ssh/sshd_config?


Generally it's a bad idea to give shell access to any account that is created just for a daemon/service to have access to particular system functions that don't require shell access. That way it'll prevent someone from breaking an (Internet-facing) service and gaining more privileges than was necessary.

Basically, why increase your attack surface if you don't need to?

On the flipside, in re-reading the question, it's not clear that nginx has has a shell account. Was nginx set up BY the guvnr account, or was it granted an actual account of its own? Every application is set up by a user, often with some administrative access. It doesn't mean that it's running AS that user always (i.e., just because cat was installed by root doesn't mean that jdoe running cat is running cat as root.) Only if nginx were running with guvnr's account privileges or as guvnr would it have access to the shell; it may very well be dropping privileges as soon as it forks or it could have its own nginx account or run as a web user account that has little or no privileges. You might want to do more digging in the config and see just what the server is running as.

  • Edited my post to reflect RTFM again :). I believe it's being run from root. Is that ok? – bottles Oct 4 '11 at 15:51
  • It means it's being installed as an elevated account, not that it's necessarily running as root. There are daemons that start with elevated privileges and drop them at runtime. Look in the config files to see if there's a user account it's specified to run as, or perhaps in Top it may show what user it's running as. – Bart Silverstrim Oct 4 '11 at 16:36
  • You're right - There's an alternate user specified in nginx.conf. – bottles Oct 4 '11 at 17:24

Because of security. If the user can't get an actual interactive shell, it's one thing less to worry about when securing your server.

Whether the user can use sudo or not has nothing to do with the user being able to open a shell.


Generally you want to give your users minimum privileges they need to do their job. Services do not need shell, so you generally wouldn't give shell access to accounts dedicated to running a daemon.

Especially, if a service accessible from network runs as a particular user, it's good idea not to give that user shell access. The reasoning is, that if your service gets compromised, then the attacker won't get shell access to the system.

If this user has a shell access, the attacker potentially has one obstacle less to overcome to take over your system. If this user has a root equivalent privileges (via sudo), then if an attacker manages to trick the system to run some command, he can do it with root authority.

While having a web server run under a uid with shell access is something you can reason about, your setup is very close to running the service as root. Bad idea IMO.

How do you administer? Either "by hand" or find a tool that does not require you to compromise your systems security.

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.