Apache configuration

Dagmar d'Surreal dagmar.wants at nospam.com
Thu Jul 24 01:37:01 PDT 2003

On Wed, 2003-07-23 at 16:27, Steve Prior wrote:
> Dagmar d'Surreal wrote:
> > Unless you're ignoring some of the many places on the web where the
> > Apache team say that the webserver should run as it's own userid and
> > groupid, no one but the webserver and the system administrator should be
> > able to read these scripts directly once they're in the DocumentRoot and
> > have their permissions set.  Hint hint.  Web pages do not need to be
> > mode 444.
> You've made me think a little about my setup and how I should clean up my act.
> I have apache running as "nobody", an account with no valid login shell. 
> However my web page directories are owned by httpd.httpd (which does have login 
> privs) and are world readable so "nobody" can see them.  How important is it for 
> apache to be run as a user with no login shell?  If it isn't a big deal, then 
> I'd be tempted to run apache as user httpd and lock down the directory 
> structure.  The other option is to remove the login shell from user httpd, run 
> apache as user httpd, and lock down the directory structure granting group privs 
> to yet another id which can write to those directories.
> What option is considered clean these days?

While it's a bit of a moot point whether or not the webserver's role
account has a valid login shell when there will be no valid password for
the account, it doesn't hurt at all to go ahead and set it to
/bin/false[1].  (Which makes it visually obvious that there should be no
password when viewing the passwd/shadow files)

The reason you want to give Apache it's own user and group to run under,
and _not_ use nobody.nogroup or similar is that regardless of it being
named "nobody" it's still a role account.  If you've got multiple things
running under this same role account, it dilutes the chain of
accountability recorded (hopefully) by the system if something starts
running amok.  For a rather poor example, if you've got Apache, BIND,
and an MTA all running as nouser.nogroup, and one day notice you're out
of disk space because there's a metric fsckton of warez and porn on the
system, all owned by nouser.nogroup, you've really got nothing much to
go on to figure out what wrote it all there.  If it happens to be owned
by named.named, then you can be pretty darn sure it was an exploitation
of the BIND daemon.  Additionally, for the really hardcore admin,
resource limits can be set on a per-user basis, and you wouldn't want
multiple things in the same category after going to that trouble.

Mind you, web pages can usually be safely owned by both the userid and
primary group being used by the webserver.  Web server configuration
files however, should be owned and writeable by some _other_ user (pref.
root or a non-root admin account), readable by the group the webserver
belongs to, and have no world permissions at all.  You don't want to
give someone who cracks your httpd the ability to easily change it's
configuration to weaken your security even further.

[1] - under some conditions this might not even get checked.
The email address above is just as phony as it looks, and for obvious reasons.
Instant messaging contact nfo: AIM: evilDagmar  Jabber: evilDagmar at jabber.org

Unsubscribe: send email to listar at linuxfromscratch.org
and put 'unsubscribe blfs-support' in the subject header of the message

More information about the blfs-support mailing list