Apache's UID/GID Usage
Walt Stoneburner
/etc/group file? ...or at least to specify multiple group ids in the
config file?
I'm getting no permission errors, and suspect I've stumbled onto an
interesting permissions problem involving the way Apache uses its GID.
I haven't been able to locate an answer in the Apache FAQ,
documentation, or bug report database.
The Problem:
On the system in question, Apache is user web and group web. In
/etc/group user web also is a member of several other groups.
/etc/passwd
web:*:888:777:Web Account:/:/bin/false
pds:x:666:555:Some User:/:/bin/bash
/etc/group
users::555
web::777:web
gean::999:web,pds
I have multiple users responsible for maintaining different parts of the
content tree; permissions are set so that groups can work only in their
directories. Observe three different kinds of file ownership issues
that Apache ought to be able to access:
-rw-rw---- pds gean somefile.html // Apache cannot read: WHY?
-rw-rw---- web gean otherfile.html // Apache can read
-rw-rw---- pds web anotherfile.html // Apache can read
Apache reports the typical no permissions error when a GET somefile.html
is performed. The other two are fine.
The Catch:
If I actually login to user web, and issue a groups command, I see both
the web and gean groups and can now access all files in question without
incident from the shell only.
However, when I use the web server to access these files, I can't. My
User and Group are both set to symbolic name web in the config file, and
even if I use the values 888 and 777 respectively, I get the same
results.
My suspicion is that when Apache firsts starts as root, it just does a
setuid/setgid and never checks to see that it can (and does) belong to
other groups as well. As such the running server never "belongs" to
group gean, except for the special case when I physically login as the
web user for diagnostics. Therefore it can not access somefile.html
because it is neither user pds or in group gean.
I don't want user pds to be able to mess with anything that isn't gean.
And he needs to be able to collaborate with other users also in the gean
group.
Is there some way to get Apache to recognize it has access to multiple
groups? I've exhausted all my known documented resources.
--Walt Stoneburner, <w...@wls.wwco.com>
Marc Slemko
>Is there a way to get Apache to honor the groups listed in the
>/etc/group file? ...or at least to specify multiple group ids in the
>config file?
What OS?
What version of Apache?
Apache does do an initgroups( which should work just fine.
Didier Godefroy
> My suspicion is that when Apache firsts starts as root, it just does a
> setuid/setgid and never checks to see that it can (and does) belong to
> other groups as well. As such the running server never "belongs" to
> group gean, except for the special case when I physically login as the
> web user for diagnostics. Therefore it can not access somefile.html
> because it is neither user pds or in group gean.
I have a situation that may be related to this, when I use ACLs to set
permissions on perl scripts and their associated files and folders, I remove
permissions to "other" completely, but the ACL does give permission specifically
to the user and group under which apache runs and executes these scripts. The
problem is that some scripts work fine that way and some others don't, they
disregard totally the ACLs that provide them proper permissions to the files
needed, and that fails these scripts.
The only way these particular scripts will run, is to re-enable the proper
permissions to "other", which shouldn't be needed since the ACLs already give
the proper permissions to the proper user and group ID for apache to work with
these files...
I'd be curious to know exactly why and if there's is a workaround that would
allow this to work without enabling the permissions to "other"..
--
Didier Godefroy
mailto:d...@ulysium.net
Walt Stoneburner
> >/etc/group file? ...or at least to specify multiple group ids in the
> >config file?
>
> What OS? What version of Apache?
Whoops, my bust. Apache 1.3.3 on Linux Slackware 3.5.