You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Greg Stein <gs...@lyra.org> on 1999/10/19 00:07:14 UTC
easy solution: Re: userspace permissions
On Mon, 18 Oct 1999, Ragnar Kurm wrote:
> my site has many users each have different virtual domain.
> apache runs as nobody.
> problem: users can access each other's docroots.
> question: if and how can i run httpd with virtual hosts so that all files
> for virtualdomain are accessed as different user. in the other words can
> apache httpd configured to have uid x if it needs to access virtual domain
> y and uid m for virtual domain n.
>
> not only cgi scripts but all other files also. 'User' configuration
> directive doesnt help me - afaik it is used only for cgi scripts.
I've read a bunch of the other responses and it seems they are all trying
to make the problem much more difficult than it needs to be. I do this all
the time, with standard configuration on my server. Of course, maybe I am
not reading your problem correctly, and if so, then please correct me.
The first thing to do is create a group, call it "www". Set up Apache to
run as nobody:www.
Next, create your virtual directories using the user, this group, and the
group-sticky bit (more in a bit):
../vhosts/:
drwxr-s--- john www john-vhost-dir
drwxr-s--- jane www jane-vhost-dir
Given this setup, you'll see than john can read his directory, and jane
can read hers. They cannot read each others -- do NOT place john/jane into
the "www" group! The web server should be the only thing in the "www"
group, and it can read/exec all the data.
Here is where the sticky bit comes into play. Note this maybe a linux-ism,
but I think (many?) other Unix platforms handle the group-sticky bit this
way, too. When john goes to create a sub-directory or a file under his
directory, the sticky bit on the parent directory will set the group to
"www" automatically. The web server will then be able to read it. A
subdirectory will even inherit the group-sticky, so that its contents will
(in turn) operate properly, too.
As a convenience, I also place symbolic links in people's home directories
to the "vhost" directory so that the users can easily reach it.
The real trick here, which others seem to have missed, is that httpd does
*not* need to change UIDs at all. Use the group semantics to do the work!
I've been running my web servers this way for several years now without a
hitch.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: easy solution: Re: userspace permissions
Posted by "James H. Cloos Jr." <cl...@jhcloos.com>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
>>>>> "Greg" == Greg Stein <gs...@lyra.org> writes:
...
Greg> The first thing to do is create a group, call it "www". Set up
Greg> Apache to run as nobody:www.
...
Greg> Next, create your virtual directories using the user, this
Greg> group, and the group-sticky bit (more in a bit):
...
Greg> Given this setup, you'll see than john can read his directory,
Greg> and jane can read hers. They cannot read each others -- do NOT
Greg> place john/jane into the "www" group! The web server should be
Greg> the only thing in the "www" group, and it can read/exec all the
Greg> data.
...
One attack on this setup is for user_i to use a CGI (or PHP, or SSI,
etc) to read the stuff under user_j's dir. In short, unless
(essentially[1]) no dynamic stuff is allowed, it solves nothing.
W/o pools per VH, you are limited to these models (in order of
increasing revenue potential):
each user get's a dir under the single hostname
name-based virtual hosts
ip-based VHs under a single daemon
ip-based VHs, one daemon per user
co-lo (ie, one box per user)
The optimal solution, of course, reminds that `everything old [can be]
new again'. All we need are virtual PCs (ala vmware & freemware) in
hardware (ala IBM's VM). (But w/o the EBCDIC, yes? :)
And one does have to wonder whether that isn't just what Transvirtual
is working on, even if noone (else) seems to be speculating in that
direction....
Until then, one can always just support all five otions above and
charge appropriately for each. Those who need actual security ought
to be willing to pay a bit more, eh?
[1] I'm sure there are dynamic environments which do not allow
arbitrary code to be run. Most, however, don't seem to fall
into that catagory.
- -JimC
- --
James H. Cloos, Jr. <URL:http://jhcloos.com/public_key> 1024D/ED7DAEA6
<cl...@jhcloos.com> E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6
Save Trees: Get E-Gold! <URL:http://jhcloos.com/go?e-gold>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.0 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE4DAypmXqfF+19rqYRAonpAJwP4RcPhiiH9+CuRt0admIukovScgCggtw7
vS7DnCDzqUzjsuj8b3HDYII=
=NQTi
-----END PGP SIGNATURE-----
Re: easy solution: Re: userspace permissions
Posted by Greg Stein <gs...@lyra.org>.
Quite true. That wasn't specified in the original problem statement,
though :-)
Man. I ought to go into politics or be a lawyer or something...
I'm not exactly sure how to munge it for that situation. It gets quite
hairy, definitely. I might just suggest eliminating filesystem access to
the group and have them do all the authoring via DAV. But that doesn't
always solve all possible problems either...
Cheers,
-g
On Mon, 18 Oct 1999, Dean Gaudet wrote:
> many of my websites are developped by a group of users... your scheme
> doesn't support that unfortunately...
>
> Dean
>
> On Mon, 18 Oct 1999, Greg Stein wrote:
>
> > The first thing to do is create a group, call it "www". Set up Apache to
> > run as nobody:www.
> >
> > Next, create your virtual directories using the user, this group, and the
> > group-sticky bit (more in a bit):
> >
> > ../vhosts/:
> > drwxr-s--- john www john-vhost-dir
> > drwxr-s--- jane www jane-vhost-dir
>
--
Greg Stein, http://www.lyra.org/
Re: easy solution: Re: userspace permissions
Posted by Dean Gaudet <dg...@arctic.org>.
many of my websites are developped by a group of users... your scheme
doesn't support that unfortunately...
Dean
On Mon, 18 Oct 1999, Greg Stein wrote:
> The first thing to do is create a group, call it "www". Set up Apache to
> run as nobody:www.
>
> Next, create your virtual directories using the user, this group, and the
> group-sticky bit (more in a bit):
>
> ../vhosts/:
> drwxr-s--- john www john-vhost-dir
> drwxr-s--- jane www jane-vhost-dir
Re: easy solution: Re: userspace permissions
Posted by Greg Stein <gs...@lyra.org>.
On Mon, 18 Oct 1999, Gary Shea wrote:
> > On Mon, 18 Oct 1999, Ragnar Kurm wrote:
> > > my site has many users each have different virtual domain.
> > > apache runs as nobody.
> > > problem: users can access each other's docroots.
> > > question: if and how can i run httpd with virtual hosts so that all files
> > > for virtualdomain are accessed as different user. in the other words can
> > > apache httpd configured to have uid x if it needs to access virtual domain
> > > y and uid m for virtual domain n.
>[...snip: solution...]
>
> I'm thinking that this is a nice idea so users can hack around
> in their directories, but am not clear on how it helps for CGI. The
> web server is running as nobody/www (say), and runs CGIs under the
> same user/group. Suppose a CGI creates a file. The resulting
> file will be owned by nobody/www, leaving the user no permissions
> (except 'other', which is presumably nothing) on the file. Am I
> missing something?
Nope... you're not missing anything at all. However, that was not in the
problem statement. "access" was the key word, not "CGI" or "modify or
create files." Some tweaking of my solution would solve this particular
issue.
Note that the problem only exists if the CGI *creates* the file. If you
CGI is only *modifying* a file, then this solution continues to work. I
don't have an answer to CGIs that create files -- I would guess that
suEXEC would be required for that particular solution. In general, I'd
simply push back on those users to have their CGI operate against existing
files rather than new files. Lastly, note that the umask would probably
create a file such as:
rw-rw-r-- nobody www cgi-created-file
The user would still be able to read the thing.
Cheers,
-g
p.s. it is possible Ragnar's request had a whole different tack (although
I don't think so, but I'm doing a bit of CYA here...). This solution is
for accesses from the filesystem; to prevent access thru the web
browser/server, that is done using Apache authentication and authorization
rules.
--
Greg Stein, http://www.lyra.org/
Re: easy solution: Re: userspace permissions
Posted by Gary Shea <sh...@gtsdesign.com>.
> On Mon, 18 Oct 1999, Ragnar Kurm wrote:
> > my site has many users each have different virtual domain.
> > apache runs as nobody.
> > problem: users can access each other's docroots.
> > question: if and how can i run httpd with virtual hosts so that all files
> > for virtualdomain are accessed as different user. in the other words can
> > apache httpd configured to have uid x if it needs to access virtual domain
> > y and uid m for virtual domain n.
>
> I've read a bunch of the other responses and it seems they are all trying
> to make the problem much more difficult than it needs to be. I do this all
> the time, with standard configuration on my server. Of course, maybe I am
> not reading your problem correctly, and if so, then please correct me.
>
> The first thing to do is create a group, call it "www". Set up Apache to
> run as nobody:www.
>
> Next, create your virtual directories using the user, this group, and the
> group-sticky bit (more in a bit):
>
> ../vhosts/:
> drwxr-s--- john www john-vhost-dir
> drwxr-s--- jane www jane-vhost-dir
I'm thinking that this is a nice idea so users can hack around
in their directories, but am not clear on how it helps for CGI. The
web server is running as nobody/www (say), and runs CGIs under the
same user/group. Suppose a CGI creates a file. The resulting
file will be owned by nobody/www, leaving the user no permissions
(except 'other', which is presumably nothing) on the file. Am I
missing something?
Gary
-----------------------------------------------------------------
Gary Shea shea@xmission.com
Salt Lake City http://www.xmission.com/~shea
Re: easy solution: Re: userspace permissions
Posted by Tony Finch <do...@dotat.at>.
Greg Stein <gs...@lyra.org> wrote:
>
>Next, create your virtual directories using the user, this group, and the
>group-sticky bit (more in a bit):
>
>drwxr-s--- john www john-vhost-dir
Apologies for being pedantic, but it's the setgid bit -- the sticky
bit has such a different meaning that mixing them up is not good!
>Here is where the sticky bit comes into play. Note this maybe a linux-ism,
>but I think (many?) other Unix platforms handle the group-sticky bit this
>way, too.
The setgid bit enables BSD file creation semantics on a sysVish Unix.
Tony.
--
dot it thus