You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Ragnar Kurm <ra...@uninet.ee> on 1999/10/18 16:58:37 UTC
userspace permissions
i'm new here, apologize if my question doesnt belong to this list.
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.
ragnar
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
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
easy solution: Re: userspace permissions
Posted by Greg Stein <gs...@lyra.org>.
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 Wilfredo Sanchez <ws...@apple.com>.
As a side note, having the web server run as nobody is somewhat
problematic if you serve NFS, since group nobody and user nobody are
NFS-isms. Generally no files on disk should be owned by nobody
(either the group or the user), since NFS maps untrusted users to
that ID. It's best, I think, to create a user specifically for the
web server.
By the way, the sticky-bit thing is a System-V-ism, which makes
file creation inherit groups BSD-style.
-Fred
--
Wilfredo Sanchez, wsanchez@apple.com
Apple Computer, Inc., Core Operating Systems / BSD
Technical Lead, Darwin Project
1 Infinite Loop, 302-4K, Cupertino, CA 95014
Re: userspace permissions
Posted by Ben Hyde <bh...@pobox.com>.
I have some preference for a model where users are given
tools to manage what is published to their site, and those
tools switch the protections so only the user runing the
server can access them directly. Works for most senarios.
- ben
Re: userspace permissions
Posted by Gary Shea <sh...@gtsdesign.com>.
> > On Mon, 18 Oct 1999, Ragnar Kurm wrote:
> >
> > > 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.
Ragnar -- This is one of those threads that come up from time to
time... I too have had this problem and have come up with a set
of patches that I use. Peter W's suggestion is surely a more secure
solution (albeit probably a bit slow), but I hacked mod_cgi and
suexec to get the needed effect. I have heard of another good solution
which I hope to put into effect one of these days. I need
per-directory control over what user/grp cgi's get run as: the idea is
to have suexec parse a config file which maps cgi directories to
user/group id. This solution requires no hacking of httpd at all,
just some major hacks to suexec. Since the Apache project folks
want nothing to do with having security alerts issued with the
Apache name all over it, they will never stand behind an iffy solution
of this kind, so we have to do it ourselves... they MIGHT let us
stick the suexec patches in their contrib directory, but I dunno...
last time I asked if I could put my newer version of the mod_cgi/suexec
patches in the contrib directory, I was met with deafening silence.
I think my old patches are still there, for 1.3b3. I'm currently
running 1.3.3 until I switch over to the pure-suexec solution.
Gary
-----------------------------------------------------------------
Gary Shea shea@xmission.com
Salt Lake City http://www.xmission.com/~shea
Re: userspace permissions
Posted by Dean Gaudet <dg...@arctic.org>.
afaik this area is still open for research... and quite an interesting
project at that.
one possibility, using something like capabilities as found in recent
linux kernels, would be to give a userid the ability to change group, but
otherwise have no special capabilities. for each website, create a group
-- which the owner(s) are a member of. then ensure all the files within
that website are readable by the group. then the webserver can switch
groups to that group when required -- otherwise it's running as its own
special uid, and has few extra privs. (this actually shouldn't require
any kernel mods, if the webserver user is just a member of all the
appropriate groups, but i don't know how many kernels handle users with >
16 groups well...)
cliff skolnick made some mods to suexec which does something along these
lines -- for similar reasons. i personally don't like suexec because it
means that my CGIs have write permissions on everything i own. i'd much
rather have a special user www-dgaudet which was a member of www-dgaudet,
and had only write perms on www-dgaudet files. dgaudet would also be a
member of www-dgaudet.
Dean
On Mon, 18 Oct 1999, Peter W wrote:
>
> This sounds like an interesting, real-world problem. Have you
> considered/tried running a separate pool of httpd's for each customer,
> each with their own uid/gid, on a diff high port, and then use the httpd
> with the VirtualHost configs to do a transparent proxy to those other
> httpd's? This would let you use a single IP address for the name-based
> virtual servers (which is the whole point, right?) while giving each
> customer the ability to safeguard their info, as well as you could
> customize for each customer things that are only available as global
> directives (like User), and maybe do even more for them, e.g. rn the
> separate customer httpd's in chroot jails.
>
> -Peter
>
> At 9:22am Oct 18, 1999, Dean Gaudet wrote:
>
> > On Mon, 18 Oct 1999, Ragnar Kurm wrote:
> >
> > > 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.
> >
> > nope.
> >
> > this would require the httpd children to run as root and setuid after
> > parsing the request... this would make some security holes compromise
> > root.
>
>
Re: userspace permissions
Posted by Peter W <pe...@usa.net>.
This sounds like an interesting, real-world problem. Have you
considered/tried running a separate pool of httpd's for each customer,
each with their own uid/gid, on a diff high port, and then use the httpd
with the VirtualHost configs to do a transparent proxy to those other
httpd's? This would let you use a single IP address for the name-based
virtual servers (which is the whole point, right?) while giving each
customer the ability to safeguard their info, as well as you could
customize for each customer things that are only available as global
directives (like User), and maybe do even more for them, e.g. rn the
separate customer httpd's in chroot jails.
-Peter
At 9:22am Oct 18, 1999, Dean Gaudet wrote:
> On Mon, 18 Oct 1999, Ragnar Kurm wrote:
>
> > 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.
>
> nope.
>
> this would require the httpd children to run as root and setuid after
> parsing the request... this would make some security holes compromise
> root.
Re: userspace permissions
Posted by Dean Gaudet <dg...@arctic.org>.
On Mon, 18 Oct 1999, Ragnar Kurm wrote:
> 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.
nope.
this would require the httpd children to run as root and setuid after
parsing the request... this would make some security holes compromise
root.
Dean