[sllug-members]: HTTP Directory Permissions Best Practices

[Lamont R. Peterson]

On Tuesday 19 September 2006 09:51am, Jeff Schroeder wrote:
> Mike asked:
> > Who should be the owners of those directories? What is the best idea
> > for permissions? Many of the directories are owned by root, and
> > readable by my apache user, but now that I am attempting to set up a
> > CMS, apache also needs to write to them.
>
> As you've discovered, things get a little trickier when you have files
> that you want to be able to change, and *also* have Apache change.  I
> don't know what the "best practices" are, but here's how I handle it.
>
> My user "jeff" is in group "users".
> The Apache user "nobody" is in group "nobody".
>
> My /home directory is chmod 705, which means it's writeable to me,
> invisible to anyone else in the "users" group, and readable to Apache.
> That's important because obviously Apache needs to be able to access
> the files to serve them.

Mode 705 is unnecessary and not safe.  Apache is started as root, but drops 
all the root privileges that it no longer needs early in it's startup.  One 
of the things it does with the root privileges it keeps, is get access to 
user's home directories under whatever director is specified with 
the "UserDir" directive.  So, Apache doesn't need any special treatment to 
your home directories.

By using a mode other than 700 for home directories, they become open to 
anyone who is not in the group which owns the home directory, not just 
Apache.

What I do on my webservers is create a group (usually called "webers" 
or "webteam" or "webs"), add the Apache user ("apache" on Red Hat, "wwwrun" 
on SUSE) to the "webs" (or whatever) group, add users who should also have 
access to the "webs" group and then use group ownership and permissions to 
control access.

If Apache should *not* have write access but the user should, the files are 
owned by the user and that user's default primary group ("users" or "staff" 
or "lamontp" or "jdoe" or whatever is appropriate) and the permissions 
without group write (this way, if the group ownership is accidentally 
changed, it doesn't open things up).

If both Apache and the user(s) *should* have write access, then the files will 
be owned by the appropriate user and the "web" (or whatever name) group and 
the group write bit will be set.

If Apache should have write access but the user(s) should not, I make the 
files owned by the Apache user ("apache", "wwwrun", whatever) and the default 
primary group for that Apache user.  Usually, I make sure the group write bit 
is not set in these cases.  In some circumstances, we want Apache to be able 
to write to certain files, but not to be able to do other things (like change 
their permissions), so I'll make those owned by the root user and the Apache 
default primary group with the group write bit set.

If you have user accounts who should only have access to their own web files 
and to web files system-wide, don't put them in the "webs" (or "webteam") 
group.

In all of these situations, I usually use mode 2770 on the base directory for 
the web files in question and make sure the appropriate group "owns" that 
directory.  This way, newly created files will always have the correct group 
ownership set on them.

Take all of this advice and use it, but you will have to adapt it to your 
needs, as there are always corner cases and unique circumstances that would, 
of course, modify these practices.  One way that I make sure the security of 
my webserver and its files is stronger is to create entries in Apache 
configuration, denying access to key files that have to be in the webspace 
(because of programmers who don't get it).  Usually, this is something like:

<Directory /dir/where/vhosts/are/example.com/www/docroot>
   <Files "^db-params.conf$">
      Order deny allow
      Deny from all
   </Files>
</Directory>

Or, if you're lucky, all the files that need protecting from the webspace will 
be in one directory, so you can ommit the <Files></Files> wrapper and just 
use the <Directory></Directory>.

> My web site files are all owned by me and chmod 644, so they're
> writeable to me only (not Apache).

That's good.

> If Apache needs to be able to create files (e.g., a CMS that allows the
> user to upload images or documents), I have a separate directory that's
> owned by me but chmod 777 so it's writeable by Apache.  The uploaded
> files are stored there, and the web site links to it to serve the
> files.

Not only is "777" writable by Apache, but it's writable by everyone.

> I've found this to be acceptable-- it gives me ultimate control over the
> files, but also permits Apache to do what it needs to do.  There are
> probably some more paranoid security things I could do if I sat down to
> ponder it, but I haven't had any problems with this setup.

We all have to balance the risks for ourselves, so if this works for you then 
go with it.  But, you might want to take another look at some of the 
potential consequences.  It looks like things are a bit more open than you 
intend them to be.  I often find another file or two to lock down when I make 
a second pass over all my webserver configuration.
-- 
Lamont R. Peterson <lamont at gurulabs.com>
Senior Instructor
Guru Labs, L.C. [ http://www.GuruLabs.com/ ]

NOTE:  All messages from this email address should be digitally signed with my
       0xDC0DD409 GPG key. It is available on the pgp.mit.edu keyserver as
       well as other keyservers that sync with MIT's.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://sllug.org/pipermail/sllug-members/attachments/20060919/72d0355f/attachment.pgp