suexec or phpsuexec ?

I posted this originally to alt.comp.lang.php but for some reason on Nildram
it doesn't update lately.

I wonder if someone conversant with Apache suexec could confirm my
understanding of this apparently popular misunderstanding. Reason being I've
recently had to move several sites from a virtual host who insisted that
they had suexec running but not phpsuexec.
Yet the only way for instance Invision and Phpauction would run was when
chgmod was set to 777 on some directories.
My understanding of the Apache docs leads me to believe that chgmod 777
would produce 500 errors as the "Nobody" users is expressly not allowed: UID
being the whole purpose of the exercise I think
Having moved these two applications to a server with suexec enabled they run
fine and all directories were revised to 755 and Nobody where tagged onto
files became UID.
It seems a popular confusion as far as I could establish with some PHP types
differentiating between PHP and other CGI scripting such as Perl: Apache
seems not to care what the CGI type is ?
Any thoughts appreciated as I'm trying to avoid putting a foot where my
mouth is.
The server that appears to have it wrong http://207.44.136.111/phpinfo.php
has the API set to Apache and
not CGI ??
Tony

--

Tony wrote:

> It seems a popular confusion as far as I could establish with some PHP types
> differentiating between PHP and other CGI scripting such as Perl: Apache
> seems not to care what the CGI type is ?

PHP scripts do no (usually) run as CGI processes, but run through mod_php
instead. This way general tools for doing stuff with CGI (such as suexec)
will not work with PHP.

--
Toby A Inkster BSc (Hons) ARCS
Contact Me - http://www.goddamn.co.uk/tobyink/?page=132

"Toby A Inkster" <tobyink@goddamn.co.uk> wrote in message
news:pan.2004.06.15.19.16.01.856237@goddamn.co.uk. ..
> Tony wrote:
>
> > It seems a popular confusion as far as I could establish with some PHP
types
> > differentiating between PHP and other CGI scripting such as Perl: Apache
> > seems not to care what the CGI type is ?
>
> PHP scripts do no (usually) run as CGI processes, but run through mod_php
> instead. This way general tools for doing stuff with CGI (such as suexec)
> will not work with PHP.
>
> --
> Toby A Inkster BSc (Hons) ARCS
> Contact Me - http://www.goddamn.co.uk/tobyink/?page=132

You may have missed the point of my enquiry - or I made it badly. All
applications I'm now running such as Invision and Phpauction run perfectly
with suexec on the new host. The misunderstanding from the old host seems to
me to be their belief that they are running suexec but NOT phpsuexec:
whereas the Apache docs indicate that phpsuexec does not as such exist ?
Apache only defines a state to allow virtual hosts to run a UID process -
and it doesn't differentiate what CGI language can or should be used.
As far as I'm concerned suexec works fine with PHP - but I was curious
where this apparent misunderstanding came from. Google for phpsuexec and all
the sites play the same tune: I think they are simply misunderstanding what
suexec is and what it does ? Possibly the terminology is just loose but from
my understanding of the Apache docs Phpsuexec is not mentioned, but it does
clearly state that error 500 will trap any attempt to use 777 under linux as
this is the user "Nobody". Scripts using 777 will simply not run under
suexec.
Yet the old host stated clearly that they were running suexec - but I had to
set directories and scripts to 777 to make Invision and Phpauction run. That
seems to indicate to me that they are talking through a fundamental orifice
other than the usual.
Tony
>

"Tony" <webfive@pantsaah-haa.com> wrote in message
news:ntadne7LS86US1PdRVn-jg@nildram.net...
> I posted this originally to alt.comp.lang.php but for some reason on Nildram
> it doesn't update lately.
>
> I wonder if someone conversant with Apache suexec could confirm my
> understanding of this apparently popular misunderstanding. Reason being I've
> recently had to move several sites from a virtual host who insisted that
> they had suexec running but not phpsuexec.
> Yet the only way for instance Invision and Phpauction would run was when
> chgmod was set to 777 on some directories.
> My understanding of the Apache docs leads me to believe that chgmod 777
> would produce 500 errors as the "Nobody" users is expressly not allowed: UID
> being the whole purpose of the exercise I think
> Having moved these two applications to a server with suexec enabled they run
> fine and all directories were revised to 755 and Nobody where tagged onto
> files became UID.
> It seems a popular confusion as far as I could establish with some PHP types
> differentiating between PHP and other CGI scripting such as Perl: Apache
> seems not to care what the CGI type is ?
> Any thoughts appreciated as I'm trying to avoid putting a foot where my
> mouth is.
> The server that appears to have it wrong http://207.44.136.111/phpinfo.php
> has the API set to Apache and
> not CGI ??

I think there may be some confusion.
Mainly because you are talking about two different things (although they can be
related:-)

chmod 777 defines who can read, write and execute - in this case everybody (777)

nobody, on the other hand is a user <sic>

What suExec is all about is when active to allow each user to run scripts under
their own uid (actually they are given temp su permissions for that task)
In effect this means that scripts can only be run as / by the user who 'owns'
them which in turn, removes the permission for nobody to do so. - (unless of
course nobody is the owner:-)

If the script is chmod 777 then the owner can still run them but non-owners will
get an internal server error (hopefully:-)

Generally, when suExec is not active then all cgi scripts run as nobody but when
it is active the scripts can only run as the owner.

Bill Logan wrote:
> ...
> I think there may be some confusion.

No?, surely not?

> Mainly because you are talking about two different things

ahhh - that would do it.
--
William Tasso

"William Tasso" <SpamBlocked@tbdata.com> wrote in message
news:2j9b9iFunrohU1@uni-berlin.de...
> Bill Logan wrote:
> > ...
> > I think there may be some confusion.
>
> No?, surely not?
>
> > Mainly because you are talking about two different things
>
> ahhh - that would do it.

Reminds me of something - I think it had to do with a cat named MacAvity and the
virtue of brevity = or something like that :-(