httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mikkel Christensen <>
Subject Re: [users@httpd] Apache refuses to start when it's user is member of to many groups
Date Sat, 08 May 2004 07:15:51 GMT
On Saturday 08 May 2004 04:31, Gary Smith wrote:
> Mikkel, 
> The reason for using user.nobody was so we didn't have to have an
> individual group per user.  We might have 50 sites per machine but each
> site may have 50-100 users.  That would be more groups than we want.
> Though it isn't much to maintain if you later delete a user and forgot
> to delete a group then you start having group id's that might be
> associated elsewhere if another user is created with the same name.

On FreeBSD which I'm running there is a command called "pw".
It's extremely easy to user from a shell-script and it automatically creates or deletes the
users corrosponding group.
Any configuration could be passed to the script as options.

This would create user and group:
/usr/sbin/pw useradd testuser -h - -s "/sbin/nologin" -L "default" -d "/nonexistent" -c "Common
user; testuser"

This deletes user and group:
/usr/bin/pw userdel testuser

By always using this I'll never forget to delete the group.

> There is also another reason...  
> The use of nobody has been long forgotten.  I can't remember why but
> there was a reason... (at least I hope there was).
> The key is that apache is not part of the nobody group.  Each user is a
> member of the nobody group (and no other).  By putting drwx---r-x on the
> users home directories the users cannot see into other users
> directories.  Apach OTOH is not a member of nobody thus falls into the
> other group.  

The problem for me is that to most users it's not a common thing setting group permissions
to zero. It's a custom thing that averybody must do each time the are uploading files.
The perfect sollution would be a safe system with default permissions since some would eventually
forget to change permissions.
Ufortunately new files created wont automatically inherit the permissions of the directory
they lies within. If so it would have been easy.

> Because of this Apache can read each users directories. 
> If we did user.user for the group then each user would have to make
> their directories readable in such a way that Apache could read which
> would leave other users able to read as well since they are not a member
> of the user.user group.

But as far as I can se other users are allowed to read the same data as apache is.
Your permissions are: rwx---r-x
The last part, r-x concerns all other users than the group and the owner. Thas is both apache
and every other user on the system.
Am I wrong or do you place apache in the same group as everybody else, thus giving apache
access means anyone has access?

> The idea is for users data to be fairly secure without breaking Apache.
> Does this make sense to this point?  If so, here is where the rest ties
> in.  Using PHP's open_basedir users can only access files that are
> within the authorized patch.  As the users home directory is in the path
> they can see and access of all of there stuff.  What a user cannot do is
> go into another users directory because it's outside their path.  This
> applies to the system call as well.  If 'cat' isn't within the path for
> open_basedir they cannot execute it.
cat is allowed bo be executed though it is not within open basedir.
All system commands are unless you specificly disable this in php.ini (or each virtual host).
Problem is that many are using unix commands so completely disabling it isn't an easy sollution.
Also open basedir does not perform any check on the information you pass to cat or whatever
program you are calling.
I just tested this to be entirely sure. You have complete and unlimited access to all that
apache is capable og reading/writing/executing.

> The other security issue that you listed was apache creating files.  For
> security reasons apache will be readonly by default for all directories.
> If the user chooses to loosen up the security (say to allow writes to
> the image folder for oscommerce or something list that) then they will
> need to change it appropriately.

I didn't think of this as a security bug. But users creating files with php will not have
access to these files through ftp, unless they change chmod with php.
Some users get confused when this happens. This is for instanse all users that are uploading
images and so on through their site.
> It's still imperfect but we are making some headway into making the
> system better.  You idea of user.user isn't bad, it's just one we
> haven't pursued extensively.  
> I'm wondering how many of the big ISP's handle their hosting.  If these
> were little web sites that didn't do much then I wouldn't be too worried
> but some of these sites store information that is very specific and
> private to their line of business.  What sucked is under Windows we did
> have the ability to modify the file permissions at the granular level.
True, but I believe that Access Lists on unix could supply the same possibilities though I'm
not familliar with them.

 - Mikkel

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