Setting the UID in a shared server environment

[Mark James <mr...@bigpond.net.au>]

I've just signed up for shared (named virtual) hosting for
my site.  The site supports mod_perl 1.27, but when I
change from the normal cgi handler to the mod_perl handler
the UID under which my scripts run changes from the UID
of my machine account/files to the UID of the apache server
(apache). This stops my scripts from working as they can no
longer write files in the account.

Is there a way for Apache or my scripts to be configured
so that I can run with the correct UID, or must I make all
my data and config files publicly writeable?

For the UID under cgi to be set correctly means that the
hosting people are using suEXEC, so where else can the UID
be set for mod_perl usage? Of course on the test server that
I fully control I just set the Apache server-level User param.

Thanks -- Mark

Re: Setting the UID in a shared server environment

["Stathy G. Touloumis" <st...@edisonaffiliates.com>]

>>The only solution I could think of after sleeping on it
>>is to request that a user-specific group be created, of
>>which only the user and the user apache are members.
>
>The thing is, if they change the UID that apache runs under, it will 
>change for eveyone, not just you.  That means that your stuff has to be 
>writeable by the user apache runs as, and anyone else writing mod_perl 
>code could potentially mess with your data files.  You are already sharing 
>a Perl interpreter with them, so they can read your variables, mess up 
>your scripts, etc.  This is what happens when you embed an interpreter in 
>the web server process.  Other technologies have the same issues with sharing.
>
>Note that this is different in apache2/mp2 where you have additional 
>options that can fix this.

How about a proxy setup?  Could use mod_rewrite to send to the appropriate 
back end process with each backend server setup for handling the specific 
user code.  May be a bitch to plan out and config but I am sure it can be 
done dynamically.  Just depends how bad you need this type of feature ;)

Might be easier just to use apache2/mp2 or wait for it to be stable.

Re: Setting the UID in a shared server environment

[Perrin Harkins <pe...@elem.com>]

Mark James wrote:
> Seems that mp1 is unusable in a shared envrionment.

It can be done, but you either have to trust the other users or use 
multiple servers with a proxy, which is a fair amount of effort for the 
ISP.  Most of us use dedicated servers.  None of the post-CGI web 
development tools are especially friendly to shared servers.  AFAIK, 
offering real safety on PHP means running it as CGI, and offering it 
with Java servlets means dedicated a VM to each user or getting into 
some messy stuff with security policies.

> I hope
> hosting providers that do enable it give very little power to
> the UID set as the Apache main-server User, otherwise users
> could cause havoc with mod_perl scripts.  Wonder if this is
> one of the main ways sites are hacked?

What, purchasing an account with the ISP in order to run mod_perl 
scripts?  That is definitely not one of the main ways sites are hacked.

- Perrin

Re: Setting the UID in a shared server environment

[Mark James <mr...@bigpond.net.au>]

Stas Bekman wrote:

> the perchild mpm:
> http://httpd.apache.org/docs-2.0/mod/perchild.html
> re: suexec and other options for mp1, see:
> http://perl.apache.org/docs/general/multiuser/multiuser.html

Thanks Stas, very helpful.

Stathy G. Touloumis wrote:
 > How about a proxy setup?  Could use mod_rewrite to send to the
 > appropriate back end process with each backend server setup for handling
 > the specific user code.  May be a bitch to plan out and config but I am
 > sure it can be done dynamically.  Just depends how bad you need this
 > type of feature ;)

Unfortunately it looks like there has to be some dedicated server
somewhere, which is incompatible with cheap hosting.

Seems that mp1 is unusable in a shared envrionment.  I hope
hosting providers that do enable it give very little power to
the UID set as the Apache main-server User, otherwise users
could cause havoc with mod_perl scripts.  Wonder if this is
one of the main ways sites are hacked?

Mark

Re: Setting the UID in a shared server environment

[Stas Bekman <st...@stason.org>]

Perrin Harkins wrote:
[...]
> Note that this is different in apache2/mp2 where you have additional 
> options that can fix this.

This is not so much a mp2 feature, but apache2's one. You need to use the 
perchild mpm:
http://httpd.apache.org/docs-2.0/mod/perchild.html
which as of this writing says:

  This MPM does not currently work on most platforms.
  Work is ongoing to make it functional.

Perhaps you may want to help polish this mpm, and once it's done you can start 
using it right away.

re: suexec and other options for mp1, see:
http://perl.apache.org/docs/general/multiuser/multiuser.html
I need to update it to include the exciting news re: perchild mpm.

__________________________________________________________________
Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

Re: Setting the UID in a shared server environment

[Mark James <mr...@bigpond.net.au>]

Perrin Harkins wrote:

> The thing is, if they change the UID that apache runs under, it will 
> change for eveyone, not just you.  That means that your stuff has to be 
> writeable by the user apache runs as, and anyone else writing mod_perl 
> code could potentially mess with your data files.  You are already 
> sharing a Perl interpreter with them, so they can read your variables, 
> mess up your scripts, etc.  This is what happens when you embed an 
> interpreter in the web server process.  Other technologies have the same 
> issues with sharing.

Right, other mod_perl users would still have write permission.
However normal hostees on this system don't have shell access, only
ftp access to their tree, so the security hole isn't gaping.

I know suEXEC mode won't run publicly writable scripts, don't know
about group writeable scripts.  If I free the permissions on my
script to make mod_perl work, I'd prefer not to make mod_cgi stop
working due to suEXEC issues.  That may be one reason to prefer
the group writable approach to the publicly writable approach.


> Note that this is different in apache2/mp2 where you have additional 
> options that can fix this.

Ah. This is one big advantage of mp2.  I hope widespread transition
begins soon.

Thanks Per	rin for the reply -- Mark

Re: Setting the UID in a shared server environment

[Perrin Harkins <pe...@elem.com>]

Mark James wrote:
> Mark James wrote:
> 
>> Is there a way for Apache or my scripts to be configured
>> so that I can run with the correct UID, or must I make all
>> my data and config files publicly writeable?
> 
> 
> The only solution I could think of after sleeping on it
> is to request that a user-specific group be created, of
> which only the user and the user apache are members.

The thing is, if they change the UID that apache runs under, it will 
change for eveyone, not just you.  That means that your stuff has to be 
writeable by the user apache runs as, and anyone else writing mod_perl 
code could potentially mess with your data files.  You are already 
sharing a Perl interpreter with them, so they can read your variables, 
mess up your scripts, etc.  This is what happens when you embed an 
interpreter in the web server process.  Other technologies have the same 
issues with sharing.

Note that this is different in apache2/mp2 where you have additional 
options that can fix this.

- Perrin

Re: Setting the UID in a shared server environment

[Mark James <mr...@bigpond.net.au>]

Mark James wrote:

> Is there a way for Apache or my scripts to be configured
> so that I can run with the correct UID, or must I make all
> my data and config files publicly writeable?

The only solution I could think of after sleeping on it
is to request that a user-specific group be created, of
which only the user and the user apache are members.