Hi,

is there a more compfortable way to pass uid/gid over to php-fpm
except for have a deamon running for every single combination?

Cheers,
Nikolas

the same daemon has a single xml file with multiple pools each pool
can have a uid/gid


On Mon, Oct 26, 2009 at 5:37 PM, Nikolas Hagelstein
<nikolas.hagelstein@googlemail.com> wrote:
>
> Hi,
>
> is there a more compfortable way to pass uid/gid over to php-fpm
> except for have a deamon running for every single combination?
>
> Cheers,
> Nikolas
>

Hi,

> the same daemon has a single xml file with multiple pools each pool
> can have a uid/gid
Ok, but how do i have to specify which pool has to used by what e.g. vhost?
Bye,
NIkolas

you assign it a different socket option or tcp address/port, and point
the specific vhost to that specific pool


On Mon, Oct 26, 2009 at 6:01 PM, Nikolas Hagelstein
<nikolas.hagelstein@googlemail.com> wrote:
>
> Hi,
>
>> the same daemon has a single xml file with multiple pools each pool
>> can have a uid/gid
> Ok, but how do i have to specify which pool has to used by what e.g. vhost?
> Bye,
> NIkolas
>

Hi,
> you assign it a different socket option or tcp address/port, and point
> the specific vhost to that specific pool
Ah ok thank you :)
Bye,
Nikolas

Say I have 20 user accounts. I don't really want to run 20 different
pools. What would be nice would be to have a single pool of say 10
phps, that get shared between all 20 accounts, rather than allocated a
set amount per account. I guess like the equivalent of running apache
with mpm itk, but for fastcgi, so you set like 20 apache processes,
and all sites share them (and switching user per site).

I don't currently use php-fpm. What are the direct advantages
currently over my current setup which is a script that launches
multiple spawn-fcgi for each user

heh, multiple spawn-fcgi per user is going to be the same deal - you
have to define a specific amount of engines per user.

the main thing missing in php-fpm is the adaptive process spawning. it
will allow you to make a pool for each user, but have low and high
limits - say, 1 or 2 engines running idle at any given time with the
ability to spike to 20, and after a certain time, idle children are
terminated. just like apache does it...

that was the last major piece missing in the code, andrei had began
adding in the required groundwork for it but never finished it.



On Mon, Nov 2, 2009 at 12:40 PM, Jools <buzz@exotica.org.uk> wrote:
>
> Say I have 20 user accounts. I don't really want to run 20 different
> pools. What would be nice would be to have a single pool of say 10
> phps, that get shared between all 20 accounts, rather than allocated a
> set amount per account. I guess like the equivalent of running apache
> with mpm itk, but for fastcgi, so you set like 20 apache processes,
> and all sites share them (and switching user per site).
>
> I don't currently use php-fpm. What are the direct advantages
> currently over my current setup which is a script that launches
> multiple spawn-fcgi for each user
>

Yeh my current spawn cgi is the same as you say, which is why I was
hoping for something better.

Having a dynamic pool would be a great feature, and may tempt me to
switch. A per server limit would be good to. so you could say. max 5
workers for user "foobar", but no more than 20 globally etc. Still
doesnt completely solve the problem that if you have lots of users,
you may still be wasting memory with a single php running for many,
and not used.

You're right it isn't 100% but if fpm can get the dynamic spawning
setup it will be the closest thing possible.

At one point I was thinking it would be cool to use regex or location
style blocks to dynamically assign uid/gid, i.e.

location /home/mike {
uid mike;
gid mike;
}

Or something


Sent from my iPhone

On Nov 2, 2009, at 3:01 PM, Jools <buzz@exotica.org.uk> wrote:

>
> Yeh my current spawn cgi is the same as you say, which is why I was
> hoping for something better.
>
> Having a dynamic pool would be a great feature, and may tempt me to
> switch. A per server limit would be good to. so you could say. max 5
> workers for user "foobar", but no more than 20 globally etc. Still
> doesnt completely solve the problem that if you have lots of users,
> you may still be wasting memory with a single php running for many,
> and not used.

Hello all,

I haven't used php-fpm yet, but it looks promising. Regarding this
thread, i was wondering if this wouldn't be the solution to my
problems.

Imagine this scenario:

A webhosting service with thousands of users, to whom php must be
provided. Each user should be locked up and restricted to it's own
account, but without being deprived of functionalities.

So far i've been able to provide such service using apache and suphp.
Although i'm pretty happy with suphp, Apache starts to have trouble
keeping up. I've already used nginx in a number of places, in a
different context, but unfortunately suphp won't work with nginx, nor
there is any similar solution, that i know of.

The closest thing i could do with nginx and fastcgi - from lighty -
would be to spawn a number of processes per user. But what to do when
we're talking about THOUSANDS of users?

In the event that php-fpm could deliver process spawning using
different UID/GID, that could be calculated in realtime, for each
access, i would switch to nginx+pgp-fpm in the blink of an eye.


Now for the suggestion:

Instead, or as a complement, to the regex way of knowing to which UID/
GID the process should run as, could i suggest the suphp way of doing
things? It's as simple as this: run the process with UID/GID of the
owner of the php script (except root of course - suphp even has
min_uid/min_gid configuration options). You could always have ways to
force the use of a certain UID or GID of course.

This approach will be great because:
- There isn't the need to chown/chmod files or directories so that
the webserver process can write into them (most modern CMS platforms
need this kind of thing nowadays)
- You can rely on file ownership to establish identity, either to
give special access to files or folders, or even provide database
access without having credentials laying around in configuration files
(see mysql sql_safe mode for instance)
- Great for troubleshooting/pest control when some of your users
misbehave, consciously or not.


Do you believe such a thing could be possible with php-fpm?

Best regards,

Hugo Monteiro.




On Nov 2, 11:26 pm, Michael Shadle <mike...@gmail.com> wrote:
> You're right it isn't 100% but if fpm can get the dynamic spawning  
> setup it will be the closest thing possible.
>
> At one point I was thinking it would be cool to use regex or location  
> style blocks to dynamically assign uid/gid, i.e.
>
> location /home/mike {
>     uid mike;
>     gid mike;
>
> }
>
> Or something
>
> Sent from my iPhone
>
> On Nov 2, 2009, at 3:01 PM, Jools <b...@exotica.org.uk> wrote:
>
>
>
>
>
> > Yeh my current spawn cgi is the same as you say, which is why I was
> > hoping for something better.
>
> > Having a dynamic pool would be a great feature, and may tempt me to
> > switch. A per server limit would be good to. so you could say. max 5
> > workers for user "foobar", but no more than 20 globally etc. Still
> > doesnt completely solve the problem that if you have lots of users,
> > you may still be wasting memory with a single php running for many,
> > and not used.

On Mon, Nov 2, 2009 at 4:51 PM, Hugo Monteiro <monteiro.hugo@gmail.com> wrote:

> A webhosting service with thousands of users, to whom php must be
> provided. Each user should be locked up and restricted to it's own
> account, but without being deprived of functionalities.

That's what I've thought about... and there isn't a solution out there
that doesn't require some idle resources being wasted currently.

> So far i've been able to provide such service using apache and suphp.
> Although i'm pretty happy with suphp, Apache starts to have trouble
> keeping up. I've already used nginx in a number of places, in a
> different context, but unfortunately suphp won't work with nginx, nor
> there is any similar solution, that i know of.

suphp sucks, I believe it forks a php-cgi process for EVERY request.
it didn't scale at all even spread over 3 webservers for me. I tried
and it failed. Originally I thought it was my golden ticket to.

> Instead, or as a complement, to the regex way of knowing to which UID/
> GID the process should run as, could i suggest the suphp way of doing
> things? It's as simple as this: run the process with UID/GID of the
> owner of the php script (except root of course - suphp even has
> min_uid/min_gid configuration options). You could always have ways to
> force the use of a certain UID or GID of course.

I still think the best approach for something like this would be a
master process that can change uid/gid context at will, and a
configuration that could be wildcarded too:

location /home/(.+)/(.+)$ {
uid $1;
gid $1;
.... maybe some limits in here or other per-user specifics ...
}

Something along that nature would be amazing.

On Nov 3, 1:03 am, Michael Shadle <mike...@gmail.com> wrote:
> On Mon, Nov 2, 2009 at 4:51 PM, Hugo Monteiro <monteiro.h...@gmail.com> wrote:
> > A webhosting service with thousands of users, to whom php must be
> > provided. Each user should be locked up and restricted to it's own
> > account, but without being deprived of functionalities.
>
> That's what I've thought about... and there isn't a solution out there
> that doesn't require some idle resources being wasted currently.
>
> > So far i've been able to provide such service using apache and suphp.
> > Although i'm pretty happy with suphp, Apache starts to have trouble
> > keeping up. I've already used nginx in a number of places, in a
> > different context, but unfortunately suphp won't work with nginx, nor
> > there is any similar solution, that i know of.
>
> suphp sucks, I believe it forks a php-cgi process for EVERY request.
> it didn't scale at all even spread over 3 webservers for me. I tried
> and it failed. Originally I thought it was my golden ticket to.
>
> > Instead, or as a complement, to the regex way of knowing to which UID/
> > GID the process should run as, could i suggest the suphp way of doing
> > things? It's as simple as this: run the process with UID/GID of the
> > owner of the php script (except root of course - suphp even has
> > min_uid/min_gid configuration options). You could always have ways to
> > force the use of a certain UID or GID of course.
>
> I still think the best approach for something like this would be a
> master process that can change uid/gid context at will, and a
> configuration that could be wildcarded too:
>
> location /home/(.+)/(.+)$ {
>    uid $1;
>    gid $1;
> ... maybe some limits in here or other per-user specifics ...
>
> }
>
> Something along that nature would be amazing.

Agreed, but let me just make a wish while i'm at it. Make it possible
to map, and use, numeric UIDs and GIDs also. You see, in my particular
setup i allow users to define and change their usernames, so /home/
webusers/johndoe is not a reality to me. Also providing matching to
e.g. /home/1000/1234 would be nicer, but you'd always end up locked up
to a "standard"(?) directory structure.
True dynamism would only be possible using php script owner matching,
or similar.

Best regards,

Hugo Monteiro.

I don't think PHP script owner matching alone would be 100% secure.
that's why Apache's suexec has so many safeguards with ownership and
parent directory ownership etc. I'm sure it took a few exploits and
years of real-world examples before getting that list right.

People smarter than I could determine if that really is "secure
enough" although my thinking is if people follow instructions and
chmod 777 things so uploads work (thinking it's typical webserver
behavior) then people can copy their own ownershipped scripts in there
and everything goes bonkers...

Although the same goes for blindly saying /home/mike should run as
mike. if a user copies rm -rf /* into my folder it will run as me
then, unless I make sure all my folders are secured properly.

And uid/gid could be uids or usernames. :) The beauty of allowing
wildcards is you could set it up however you wanted. Although I
wouldn't allow subdirs to be matched, because I could create
/home/foo/mike and if you allow a second level to pass in as the uid,
you'll be executing scripts as me...seems every way has some
complications.

On Mon, Nov 2, 2009 at 5:23 PM, Hugo Monteiro <monteiro.hugo@gmail.com> wrote:
>
>
>
> On Nov 3, 1:03 am, Michael Shadle <mike...@gmail.com> wrote:
>> On Mon, Nov 2, 2009 at 4:51 PM, Hugo Monteiro <monteiro.h...@gmail.com> wrote:
>> > A webhosting service with thousands of users, to whom php must be
>> > provided. Each user should be locked up and restricted to it's own
>> > account, but without being deprived of functionalities.
>>
>> That's what I've thought about... and there isn't a solution out there
>> that doesn't require some idle resources being wasted currently.
>>
>> > So far i've been able to provide such service using apache and suphp.
>> > Although i'm pretty happy with suphp, Apache starts to have trouble
>> > keeping up. I've already used nginx in a number of places, in a
>> > different context, but unfortunately suphp won't work with nginx, nor
>> > there is any similar solution, that i know of.
>>
>> suphp sucks, I believe it forks a php-cgi process for EVERY request.
>> it didn't scale at all even spread over 3 webservers for me. I tried
>> and it failed. Originally I thought it was my golden ticket to.
>>
>> > Instead, or as a complement, to the regex way of knowing to which UID/
>> > GID the process should run as, could i suggest the suphp way of doing
>> > things? It's as simple as this: run the process with UID/GID of the
>> > owner of the php script (except root of course - suphp even has
>> > min_uid/min_gid configuration options). You could always have ways to
>> > force the use of a certain UID or GID of course.
>>
>> I still think the best approach for something like this would be a
>> master process that can change uid/gid context at will, and a
>> configuration that could be wildcarded too:
>>
>> location /home/(.+)/(.+)$ {
>>    uid $1;
>>    gid $1;
>> ... maybe some limits in here or other per-user specifics ...
>>
>> }
>>
>> Something along that nature would be amazing.
>
> Agreed, but let me just make a wish while i'm at it. Make it possible
> to map, and use, numeric UIDs and GIDs also. You see, in my particular
> setup i allow users to define and change their usernames, so /home/
> webusers/johndoe is not a reality to me. Also providing matching to
> e.g. /home/1000/1234 would be nicer, but you'd always end up locked up
> to a "standard"(?) directory structure.
> True dynamism would only be possible using php script owner matching,
> or similar.
>
> Best regards,
>
> Hugo Monteiro.
>

On Nov 3, 1:28 am, Michael Shadle <mike...@gmail.com> wrote:
> I don't think PHP script owner matching alone would be 100% secure.
> that's why Apache's suexec has so many safeguards with ownership and
> parent directory ownership etc. I'm sure it took a few exploits and
> years of real-world examples before getting that list right.
>
> People smarter than I could determine if that really is "secure
> enough" although my thinking is if people follow instructions and
> chmod 777 things so uploads work (thinking it's typical webserver
> behavior) then people can copy their own ownershipped scripts in there
> and everything goes bonkers...
>

You're forgetting about something. If that user is able to upload the
script to your homedir, it will still be owned by him, not you. So
even if he is able to run it, it will run with HIS uid, not yours.
Now about permissions. You can and SHOULD enforce secure permissions
to the file being transfered to your webserver, whatever is the
solution you're using, either if they fly over an ftp server or plain
a php upload php script. Any modern ftp server will allow you to
enforce not only ownership but also file permissions. Also, if you
follow suphp's example, you could come up with a umask setting that
would default the perms of the files to whatever value the service
administrator defines.

> Although the same goes for blindly saying /home/mike should run as
> mike. if a user copies rm -rf /* into my folder it will run as me
> then, unless I make sure all my folders are secured properly.
>

That is true in the approach you're suggesting. Having a file in a
certain folder is in fact no way to guarantee that it's a legitimate
user file.

> And uid/gid could be uids or usernames. :) The beauty of allowing
> wildcards is you could set it up however you wanted. Although I
> wouldn't allow subdirs to be matched, because I could create
> /home/foo/mike and if you allow a second level to pass in as the uid,
> you'll be executing scripts as me...seems every way has some
> complications.
>


Also, don't forget that regex implementation would probably be much
more worky than using a simple stat()



R's,

Hugo Monteiro.

>
>
> On Mon, Nov 2, 2009 at 5:23 PM, Hugo Monteiro <monteiro.h...@gmail.com> wrote:
>
> > On Nov 3, 1:03 am, Michael Shadle <mike...@gmail.com> wrote:
> >> On Mon, Nov 2, 2009 at 4:51 PM, Hugo Monteiro <monteiro.h...@gmail.com> wrote:
> >> > A webhosting service with thousands of users, to whom php must be
> >> > provided. Each user should be locked up and restricted to it's own
> >> > account, but without being deprived of functionalities.
>
> >> That's what I've thought about... and there isn't a solution out there
> >> that doesn't require some idle resources being wasted currently.
>
> >> > So far i've been able to provide such service using apache and suphp.
> >> > Although i'm pretty happy with suphp, Apache starts to have trouble
> >> > keeping up. I've already used nginx in a number of places, in a
> >> > different context, but unfortunately suphp won't work with nginx, nor
> >> > there is any similar solution, that i know of.
>
> >> suphp sucks, I believe it forks a php-cgi process for EVERY request.
> >> it didn't scale at all even spread over 3 webservers for me. I tried
> >> and it failed. Originally I thought it was my golden ticket to.
>
> >> > Instead, or as a complement, to the regex way of knowing to which UID/
> >> > GID the process should run as, could i suggest the suphp way of doing
> >> > things? It's as simple as this: run the process with UID/GID of the
> >> > owner of the php script (except root of course - suphp even has
> >> > min_uid/min_gid configuration options). You could always have ways to
> >> > force the use of a certain UID or GID of course.
>
> >> I still think the best approach for something like this would be a
> >> master process that can change uid/gid context at will, and a
> >> configuration that could be wildcarded too:
>
> >> location /home/(.+)/(.+)$ {
> >>    uid $1;
> >>    gid $1;
> >> ... maybe some limits in here or other per-user specifics ...
>
> >> }
>
> >> Something along that nature would be amazing.
>
> > Agreed, but let me just make a wish while i'm at it. Make it possible
> > to map, and use, numeric UIDs and GIDs also. You see, in my particular
> > setup i allow users to define and change their usernames, so /home/
> > webusers/johndoe is not a reality to me. Also providing matching to
> > e.g. /home/1000/1234 would be nicer, but you'd always end up locked up
> > to a "standard"(?) directory structure.
> > True dynamism would only be possible using php script owner matching,
> > or similar.
>
> > Best regards,
>
> > Hugo Monteiro.

You should enforce but if you're running a hosting service people will
mess it up period. Even scripts owned properly can be exploited and
don't even need root to do damage.

I can't think about my example of copying a script you own to someone
elses dir... I had it in my mind but I'm driving and too hungry to
remember :)

Sent from my iPhone

On Nov 2, 2009, at 5:44 PM, Hugo Monteiro <monteiro.hugo@gmail.com>
wrote:

>
>
>
> On Nov 3, 1:28 am, Michael Shadle <mike...@gmail.com> wrote:
>> I don't think PHP script owner matching alone would be 100% secure.
>> that's why Apache's suexec has so many safeguards with ownership and
>> parent directory ownership etc. I'm sure it took a few exploits and
>> years of real-world examples before getting that list right.
>>
>> People smarter than I could determine if that really is "secure
>> enough" although my thinking is if people follow instructions and
>> chmod 777 things so uploads work (thinking it's typical webserver
>> behavior) then people can copy their own ownershipped scripts in
>> there
>> and everything goes bonkers...
>>
>
> You're forgetting about something. If that user is able to upload the
> script to your homedir, it will still be owned by him, not you. So
> even if he is able to run it, it will run with HIS uid, not yours.
> Now about permissions. You can and SHOULD enforce secure permissions
> to the file being transfered to your webserver, whatever is the
> solution you're using, either if they fly over an ftp server or plain
> a php upload php script. Any modern ftp server will allow you to
> enforce not only ownership but also file permissions. Also, if you
> follow suphp's example, you could come up with a umask setting that
> would default the perms of the files to whatever value the service
> administrator defines.
>
>> Although the same goes for blindly saying /home/mike should run as
>> mike. if a user copies rm -rf /* into my folder it will run as me
>> then, unless I make sure all my folders are secured properly.
>>
>
> That is true in the approach you're suggesting. Having a file in a
> certain folder is in fact no way to guarantee that it's a legitimate
> user file.
>
>> And uid/gid could be uids or usernames. :) The beauty of allowing
>> wildcards is you could set it up however you wanted. Although I
>> wouldn't allow subdirs to be matched, because I could create
>> /home/foo/mike and if you allow a second level to pass in as the uid,
>> you'll be executing scripts as me...seems every way has some
>> complications.
>>
>
>
> Also, don't forget that regex implementation would probably be much
> more worky than using a simple stat()
>
>
>
> R's,
>
> Hugo Monteiro.
>
>>
>>
>> On Mon, Nov 2, 2009 at 5:23 PM, Hugo Monteiro
>> <monteiro.h...@gmail.com> wrote:
>>
>>> On Nov 3, 1:03 am, Michael Shadle <mike...@gmail.com> wrote:
>>>> On Mon, Nov 2, 2009 at 4:51 PM, Hugo Monteiro
>>>> <monteiro.h...@gmail.com> wrote:
>>>>> A webhosting service with thousands of users, to whom php must be
>>>>> provided. Each user should be locked up and restricted to it's own
>>>>> account, but without being deprived of functionalities.
>>
>>>> That's what I've thought about... and there isn't a solution out
>>>> there
>>>> that doesn't require some idle resources being wasted currently.
>>
>>>>> So far i've been able to provide such service using apache and
>>>>> suphp.
>>>>> Although i'm pretty happy with suphp, Apache starts to have
>>>>> trouble
>>>>> keeping up. I've already used nginx in a number of places, in a
>>>>> different context, but unfortunately suphp won't work with
>>>>> nginx, nor
>>>>> there is any similar solution, that i know of.
>>
>>>> suphp sucks, I believe it forks a php-cgi process for EVERY
>>>> request.
>>>> it didn't scale at all even spread over 3 webservers for me. I
>>>> tried
>>>> and it failed. Originally I thought it was my golden ticket to.
>>
>>>>> Instead, or as a complement, to the regex way of knowing to
>>>>> which UID/
>>>>> GID the process should run as, could i suggest the suphp way of
>>>>> doing
>>>>> things? It's as simple as this: run the process with UID/GID of
>>>>> the
>>>>> owner of the php script (except root of course - suphp even has
>>>>> min_uid/min_gid configuration options). You could always have
>>>>> ways to
>>>>> force the use of a certain UID or GID of course.
>>
>>>> I still think the best approach for something like this would be a
>>>> master process that can change uid/gid context at will, and a
>>>> configuration that could be wildcarded too:
>>
>>>> location /home/(.+)/(.+)$ {
>>>> uid $1;
>>>> gid $1;
>>>> ... maybe some limits in here or other per-user specifics ...
>>
>>>> }
>>
>>>> Something along that nature would be amazing.
>>
>>> Agreed, but let me just make a wish while i'm at it. Make it
>>> possible
>>> to map, and use, numeric UIDs and GIDs also. You see, in my
>>> particular
>>> setup i allow users to define and change their usernames, so /home/
>>> webusers/johndoe is not a reality to me. Also providing matching to
>>> e.g. /home/1000/1234 would be nicer, but you'd always end up
>>> locked up
>>> to a "standard"(?) directory structure.
>>> True dynamism would only be possible using php script owner
>>> matching,
>>> or similar.
>>
>>> Best regards,
>>
>>> Hugo Monteiro.

On Nov 3, 1:48 am, Michael Shadle <mike...@gmail.com> wrote:
> You should enforce but if you're running a hosting service people will  
> mess it up period. Even scripts owned properly can be exploited and  
> don't even need root to do damage.
>


True, but having each user confined to their own homedirs, the damage
would only happen within their own account, which in the end is their
own responsibility. Users must be responsible for the crappy php code
they have in their own pages and you can't do anything about that one.
The issue here is finding a way to contain that crappy code so that:

1 - It can't harm your system.
2 - It can't harm or jeapordize other users content.

> I can't think about my example of copying a script you own to someone  
> elses dir... I had it in my mind but I'm driving and too hungry to  
> remember :)
>

Have a nice lunch/dinner. =)

> Sent from my iPhone
>
> On Nov 2, 2009, at 5:44 PM, Hugo Monteiro <monteiro.h...@gmail.com>  
> wrote:
>
>
>
>
>
> > On Nov 3, 1:28 am, Michael Shadle <mike...@gmail.com> wrote:
> >> I don't think PHP script owner matching alone would be 100% secure.
> >> that's why Apache's suexec has so many safeguards with ownership and
> >> parent directory ownership etc. I'm sure it took a few exploits and
> >> years of real-world examples before getting that list right.
>
> >> People smarter than I could determine if that really is "secure
> >> enough" although my thinking is if people follow instructions and
> >> chmod 777 things so uploads work (thinking it's typical webserver
> >> behavior) then people can copy their own ownershipped scripts in  
> >> there
> >> and everything goes bonkers...
>
> > You're forgetting about something. If that user is able to upload the
> > script to your homedir, it will still be owned by him, not you. So
> > even if he is able to run it, it will run with HIS uid, not yours.
> > Now about permissions. You can and SHOULD enforce secure permissions
> > to the file being transfered to your webserver, whatever is the
> > solution you're using, either if they fly over an ftp server or plain
> > a php upload php script. Any modern ftp server will allow you to
> > enforce not only ownership but also file permissions. Also, if you
> > follow suphp's example, you could come up with a umask setting that
> > would default the perms of the files to whatever value the service
> > administrator defines.
>
> >> Although the same goes for blindly saying /home/mike should run as
> >> mike. if a user copies rm -rf /* into my folder it will run as me
> >> then, unless I make sure all my folders are secured properly.
>
> > That is true in the approach you're suggesting. Having a file in a
> > certain folder is in fact no way to guarantee that it's a legitimate
> > user file.
>
> >> And uid/gid could be uids or usernames. :) The beauty of allowing
> >> wildcards is you could set it up however you wanted. Although I
> >> wouldn't allow subdirs to be matched, because I could create
> >> /home/foo/mike and if you allow a second level to pass in as the uid,
> >> you'll be executing scripts as me...seems every way has some
> >> complications.
>
> > Also, don't forget that regex implementation would probably be much
> > more worky than using a simple stat()
>
> > R's,
>
> > Hugo Monteiro.
>
> >> On Mon, Nov 2, 2009 at 5:23 PM, Hugo Monteiro  
> >> <monteiro.h...@gmail.com> wrote:
>
> >>> On Nov 3, 1:03 am, Michael Shadle <mike...@gmail.com> wrote:
> >>>> On Mon, Nov 2, 2009 at 4:51 PM, Hugo Monteiro  
> >>>> <monteiro.h...@gmail.com> wrote:
> >>>>> A webhosting service with thousands of users, to whom php must be
> >>>>> provided. Each user should be locked up and restricted to it's own
> >>>>> account, but without being deprived of functionalities.
>
> >>>> That's what I've thought about... and there isn't a solution out  
> >>>> there
> >>>> that doesn't require some idle resources being wasted currently.
>
> >>>>> So far i've been able to provide such service using apache and  
> >>>>> suphp.
> >>>>> Although i'm pretty happy with suphp, Apache starts to have  
> >>>>> trouble
> >>>>> keeping up. I've already used nginx in a number of places, in a
> >>>>> different context, but unfortunately suphp won't work with  
> >>>>> nginx, nor
> >>>>> there is any similar solution, that i know of.
>
> >>>> suphp sucks, I believe it forks a php-cgi process for EVERY  
> >>>> request.
> >>>> it didn't scale at all even spread over 3 webservers for me. I  
> >>>> tried
> >>>> and it failed. Originally I thought it was my golden ticket to.
>
> >>>>> Instead, or as a complement, to the regex way of knowing to  
> >>>>> which UID/
> >>>>> GID the process should run as, could i suggest the suphp way of  
> >>>>> doing
> >>>>> things? It's as simple as this: run the process with UID/GID of  
> >>>>> the
> >>>>> owner of the php script (except root of course - suphp even has
> >>>>> min_uid/min_gid configuration options). You could always have  
> >>>>> ways to
> >>>>> force the use of a certain UID or GID of course.
>
> >>>> I still think the best approach for something like this would be a
> >>>> master process that can change uid/gid context at will, and a
> >>>> configuration that could be wildcarded too:
>
> >>>> location /home/(.+)/(.+)$ {
> >>>>    uid $1;
> >>>>    gid $1;
> >>>> ... maybe some limits in here or other per-user specifics ...
>
> >>>> }
>
> >>>> Something along that nature would be amazing.
>
> >>> Agreed, but let me just make a wish while i'm at it. Make it  
> >>> possible
> >>> to map, and use, numeric UIDs and GIDs also. You see, in my  
> >>> particular
> >>> setup i allow users to define and change their usernames, so /home/
> >>> webusers/johndoe is not a reality to me. Also providing matching to
> >>> e.g. /home/1000/1234 would be nicer, but you'd always end up  
> >>> locked up
> >>> to a "standard"(?) directory structure.
> >>> True dynamism would only be possible using php script owner  
> >>> matching,
> >>> or similar.
>
> >>> Best regards,
>
> >>> Hugo Monteiro.

On Mon, Nov 2, 2009 at 6:05 PM, Hugo Monteiro <monteiro.hugo@gmail.com> wrote:

> True, but having each user confined to their own homedirs, the damage
> would only happen within their own account, which in the end is their
> own responsibility. Users must be responsible for the crappy php code
> they have in their own pages and you can't do anything about that one.
> The issue here is finding a way to contain that crappy code so that:
>
> 1 - It can't harm your system.

When you have a $2000 bandwidth bill because someone's PHP script got
exploited and was capable of unpacking an XDCC eggdrop bot, you'll
re-think that statement :)

On Nov 3, 2:13 am, Michael Shadle <mike...@gmail.com> wrote:
> On Mon, Nov 2, 2009 at 6:05 PM, Hugo Monteiro <monteiro.h...@gmail.com> wrote:
> > True, but having each user confined to their own homedirs, the damage
> > would only happen within their own account, which in the end is their
> > own responsibility. Users must be responsible for the crappy php code
> > they have in their own pages and you can't do anything about that one.
> > The issue here is finding a way to contain that crappy code so that:
>
> > 1 - It can't harm your system.
>
> When you have a $2000 bandwidth bill because someone's PHP script got
> exploited and was capable of unpacking an XDCC eggdrop bot, you'll
> re-think that statement :)


There are ways to set max execution time for processes, and their
children. =)


R's,

Hugo Monteiro.

On Nov 3, 2:55 am, Hugo Monteiro <monteiro.h...@gmail.com> wrote:
> On Nov 3, 2:13 am, Michael Shadle <mike...@gmail.com> wrote:
>
> > On Mon, Nov 2, 2009 at 6:05 PM, Hugo Monteiro <monteiro.h...@gmail.com> wrote:
> > > True, but having each user confined to their own homedirs, the damage
> > > would only happen within their own account, which in the end is their
> > > own responsibility. Users must be responsible for the crappy php code
> > > they have in their own pages and you can't do anything about that one.
> > > The issue here is finding a way to contain that crappy code so that:
>
> > > 1 - It can't harm your system.
>
> > When you have a $2000 bandwidth bill because someone's PHP script got
> > exploited and was capable of unpacking an XDCC eggdrop bot, you'll
> > re-think that statement :)
>
> There are ways to set max execution time for processes, and their
> children. =)
>

AND bandwidth limitation per user.

> R's,
>
> Hugo Monteiro.

On Mon, Nov 2, 2009 at 6:55 PM, Hugo Monteiro <monteiro.hugo@gmail.com> wrote:

>> When you have a $2000 bandwidth bill because someone's PHP script got
>> exploited and was capable of unpacking an XDCC eggdrop bot, you'll
>> re-think that statement :)
>
>
> There are ways to set max execution time for processes, and their
> children. =)

Don't think it works when something is forked in the background...

This was before PHP-FPM anyway. Who knows, maybe the script would have
been killed by it beforehand.