httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David A. Gershman" <>
Subject Re: [users@httpd] CGI File Permissions...(not trivial question)
Date Tue, 14 Oct 2003 17:49:50 GMT

I don't want to belabor this stuff but I think my original email was a
little unclear.  Sorry for the long response/explanation, but...

> needs to be readable by ann and sundry, executable alone is not
> enough. Try 755. 
  Quick response: 755 = insecure against file system users

> Also, what identity is apache running as?
> Nornmally, it is 'nobody'. If the first suggestion barks like a dog,
> try changing ownership to 'nobody:nobody'. 755 is really the
> permission of preference. ALs, check the cgi-bin directory's
> permissions and ownerships! 
  Quick response : directory permissions and ownership are fine
                   because the script ran with 755 permissions

> If You read the stuff carefully, You'll find the some answers on:
> > Question: Why won't the script run with restricted permissions?
> > If this is some sort of security feature...why?  What risk am I
> > not seeing???

  Quick response : First, I apologize.  I didn't read it before.  I
                   have now and hence my thinking I was unclear in my
                   original email.

Original email synopsis
* apache 1.3.28 running as 'apache' user and 'apache' group
* web docs and cgis owned as 'www' user and 'www' group
* 'apache' user is a member of 'www' group

Given a script with perms:

   -rwxr-x---    1 www      www           144 Oct 13 11:40*

Logging in as 'apache' allows execution of script.  Execution via web
server results in 'file permissions deny server execution...' in

Ok, with this in mind I will start from the beginning so I don't
confuse anyone (including myself).  First it should be said my
configuration is not good for all web environments (yet *smirk*).  I
currently have only had users who maintain their own web sites and not
aid in the development in others (i.e. group permissions may be needed).

The security model I desire is as follows.  I have all files owned by
'www'/'www'.  However, I run the web server as 'apache'/'apache'.
This allows the apache user no access to anything except that which I
explicitly give it via group permissions (since 'apache' is a member
of 'www').  Example, I must give apache full write privileges to the
log directory.

'www's umask is 027, thus all files have no world permissions.  Why?
I consider this insecure.  Consider the current "convention" where
.html files need world readable permissions for the web server to gain
access to them.  Now consider I want some files password protected for
limited viewing.  So, I provide a .htaccess and now the directory
requires a password for anyone to view it, right?  Wrong!  *ONLY* web
viewers are required to provide a password.  Any other user *on the
file system* still can view my files due to the world readability.

This problem also exists for CGIs.  If I make any CGI world executable
for the web server to gain access to it, any file system user can also
execute it with no password requirements (unless the CGI itself
handles passwords).

To get around this, I eliminate world permissions altogether and put
the 'apache' user into the group of each user (who btw has their own
group, i.e. 'user1' user with group 'user1' and 'apache' a member of
'user1').  Now, the web server can get to group readable files, but
other users on the file system, still cannot.  Does this allow
readability for all files in the users account by 'apache'?  Yes, only
if group permissions exist.  Is this a problem, no.  No one has access
to the 'apache' account unless by exploit.  But even then, they would
only have read access unless the user explicitly allowed write.  Plus,
if the file is not to be web viewed, there is no reason why not to
remove group permissions.  In fact a users umask could be set to 077
and then force them to set appropriate permissions only for web
viewable files. 

The part of my original email I think was unclear is that the 'www'
user is my server's user for system based .html and cgis 
instead of 'apache' owning those (i.e. the server is configured for
the DocumentRoot and ScriptAlias to point to these).  So no one except
for trusted individuals (for now, just me) have access to the  'www'
account. Thus all .html and cgi files can only be modified by me (via
su'ing to 'www'). 

Ok, so why do all this.  If the 'apache' user and group are gained via
some bug/hole/exploit, whatever, this setup prevents web site
defacement, cgi modification, etc.  The intruder can't even modify the
config files.  They only have write access to whatever I have
explicitly provided (and hopefully made security wise). For example,
they could "cover their tracks" by wiping out my log files or examine
the CGIs to see if write access exists to anything.

As for the CGIs owned by 'www'/'www', with 'apache' in group 'www',
and the permission on the cgi set to 750, the 'apache' server should
be able to execute the 'apache' which is desirable.  I do
*not* want these CGIs run as 'www'.  (For user based CGIs I prefer
CGIwrap to suExec).

In the apache code, a compiler directive MULTIPLE_GROUPS needs to be
defined in src/include/httpd.h.  This directive will allow the
inclusion of code which checks for not just 'apache' user/group
executability, but also the other groups 'apache' is a member
of...i.e. 'www'.  Hence the script runs as 'apache', but with perms
750 owned by 'www'/'www'.  Is this a danger for users?  No.  The web
server does not have a ScriptAlias set for user CGIs...hence the
purpose of CgiWrap which will run the scripts as that particular user.

I know this email was long, but I hope I cleared things up and even
perhaps provided some helpful info.

If you have any suggestions or know of risks/security issues with my
setup, please by all means let me know.  Thanks.

David A. Gershman
ETC Sys Admin

The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:> for more info.
To unsubscribe, e-mail:
   "   from the digest:
For additional commands, e-mail:

View raw message