php-general Digest 21 Oct 2006 11:02:46 -0000 Issue 4413
Topics (messages 243415 through 243420):
Daylight saving time
243415 by: Raphael Chasse
Re: User question for PHP
243416 by: chris smith
243418 by: Jochem Maas
243419 by: chris smith
Re: Creating Tree Structure from associative array
243417 by: Jochem Maas
Re: Weird stack trace in error_log from PDOException
243420 by: Roman Neuhauser
Administrivia:
To subscribe to the digest, e-mail:
[EMAIL PROTECTED]
To unsubscribe from the digest, e-mail:
[EMAIL PROTECTED]
To post to the list, e-mail:
php-general@lists.php.net
----------------------------------------------------------------------
--- Begin Message ---
Hello,
Regarding PHP5 bug #35296, http://bugs.php.net/bug.php?id=35296
I assume that it has been fixed in PHP5 for a while now (any version higher
than PHP 5.0.5 ).
Could someone tell me if PHP4 has been corrected as well ? in other word, what
is the oldest version of PHP4 that contains the bug fix ?
Thank you,
--
Raphaël Chassé
--- End Message ---
--- Begin Message ---
On 10/21/06, Ivo F.A.C. Fokkema <[EMAIL PROTECTED]> wrote:
On Fri, 20 Oct 2006 23:24:14 +1000, chris smith wrote:
> On 10/20/06, Ivo F.A.C. Fokkema <[EMAIL PROTECTED]> wrote:
>> On Fri, 20 Oct 2006 15:49:14 +1000, Chris wrote:
>>
>> > Andy Hultgren wrote:
>> >> To whoever was asking this (sorry didn't see the original email):
>> >>
>> >>>> Is it possible to have a PHP script execute as the user of the domain
>> >>>> instead of the webserver? So when I upload files through a PHP script
>> >>>> they are owned by me and not "wwwrun" or "nobody"?
>> >>
>> >> I was recently exchanging on this list about that very topic. It's in the
>> >> archives for this list. Go to www.php.net and set the dropdown menu in
the
>> >> upper right corner of the page to "general mailing list", then type "File
>> >> Upload Security and chmod" into the search field and hit enter. The
>> >> conversation is within the first few hits on this search.
>> >> The server hosting my site runs with php executing as "me" (the owner of
>> >> the
>> >> domain), and we covered some of the potential security pitfalls of such a
>> >> situation (mainly centered on the fact that this makes any php script far
>> >> too powerful). In my situation I couldn't change how the server was set
>> >> up;
>> >> however, the general consensus was that this situation created a number of
>> >> serious security concerns that had to be very carefully addressed. I
would
>> >> avoid this configuration if you have the choice, based purely on the
advice
>> >> I received.
>> >
>> > Actually you have that the wrong way around.
>> >
>> > If php is running as "www" or "nobody" then any files or directories
>> > that a php script creates will be done as the web server user.
>> >
>> > That means (potentially) that if domain 'a' creates a file, domain 'b'
>> > can read and write to that file and even delete it.
>> >
>> >
>> > If php is running as you instead, you can control this with appropriate
>> > chmod commands (at least removing the risk of deleting of files /
>> > updating of files).
>> >
>> > A shared user (like "www" or "nobody") is a *much* bigger risk than
>> > separate users.
>>
>> Unless those separate users have a little more access than just SSH
>> and FTP access to the machine... I guess that if anyone with special
>> rights carelessly activates suPHP and leaves the PHP files owned by him,
>> you'd have PHP scripts capable of reading out special log files and
>> whatnot.
>>
>> To my experience, apache (with PHP running as www-data or nobody or
>> whatever) will not be able to create files or folders without user
>> intervention (chmod, chown), thus no updating and removing is possible
>> either by default.
>
> php running through apache:
>
> <?php
> mkdir('/path/to/dir');
> ?>
>
> Making that in a "shared" location will allow *any* domain to write to
> it, read from it or delete it (forget about possible open_basedir
> restrictions).
I see your point and I agree this is an issue, but given the
relatively small incidence of such a situation, I personally would not say
this is a much bigger problem than a PHP file being able to remove all
other files owned by the same owner (i.e. usually the whole site at least)...
Running it as separate users removes safe-mode problems (the file
uploaded will be as "www" or "nobody", the script trying to access it
is "user"), stops you having to have '777' type permissions on "temp"
or "data" directories, "user a" can't do anything to "user b"s files
and so on. Plus if your domain gets hacked through php, they can
*only* do damage to your domain. They'd have to hack the other domains
on the server because they are owned by different users...
--
Postgresql & php tutorials
http://www.designmagick.com/
--- End Message ---
--- Begin Message ---
chris smith wrote:
> On 10/21/06, Ivo F.A.C. Fokkema <[EMAIL PROTECTED]> wrote:
>> On Fri, 20 Oct 2006 23:24:14 +1000, chris smith wrote:
>>
>> > On 10/20/06, Ivo F.A.C. Fokkema <[EMAIL PROTECTED]> wrote:
....
>> >>
>> >> To my experience, apache (with PHP running as www-data or nobody or
>> >> whatever) will not be able to create files or folders without user
>> >> intervention (chmod, chown), thus no updating and removing is possible
>> >> either by default.
>> >
>> > php running through apache:
>> >
>> > <?php
>> > mkdir('/path/to/dir');
>> > ?>
>> >
>> > Making that in a "shared" location will allow *any* domain to write to
>> > it, read from it or delete it (forget about possible open_basedir
>> > restrictions).
>>
>> I see your point and I agree this is an issue, but given the
>> relatively small incidence of such a situation, I personally would not
>> say
>> this is a much bigger problem than a PHP file being able to remove all
>> other files owned by the same owner (i.e. usually the whole site at
>> least)...
>
> Running it as separate users removes safe-mode problems (the file
> uploaded will be as "www" or "nobody", the script trying to access it
> is "user"), stops you having to have '777' type permissions on "temp"
> or "data" directories, "user a" can't do anything to "user b"s files
> and so on.
but php and the webserver now has full rights over all your files not just
a few of your designated data files. e.g.
exec('rm ~/.ssh/*'); // nice
maybe you should check out open_base_dir, for instance set it in the vhost
config:
php_admin_value open_base_dir
"/path2/2/web/include_dir:/path/2/webroot:/usr/lib/php:";
> Plus if your domain gets hacked through php, they can
> *only* do damage to your domain. They'd have to hack the other domains
> on the server because they are owned by different users...
how relevant is this is in relation to actual cracking practices (e.g.
escalating
privelege to root)? and doesn't 'open base dir' solve this just as well?
>
--- End Message ---
--- Begin Message ---
On 10/21/06, Jochem Maas <[EMAIL PROTECTED]> wrote:
chris smith wrote:
> On 10/21/06, Ivo F.A.C. Fokkema <[EMAIL PROTECTED]> wrote:
>> On Fri, 20 Oct 2006 23:24:14 +1000, chris smith wrote:
>>
>> > On 10/20/06, Ivo F.A.C. Fokkema <[EMAIL PROTECTED]> wrote:
....
>> >>
>> >> To my experience, apache (with PHP running as www-data or nobody or
>> >> whatever) will not be able to create files or folders without user
>> >> intervention (chmod, chown), thus no updating and removing is possible
>> >> either by default.
>> >
>> > php running through apache:
>> >
>> > <?php
>> > mkdir('/path/to/dir');
>> > ?>
>> >
>> > Making that in a "shared" location will allow *any* domain to write to
>> > it, read from it or delete it (forget about possible open_basedir
>> > restrictions).
>>
>> I see your point and I agree this is an issue, but given the
>> relatively small incidence of such a situation, I personally would not
>> say
>> this is a much bigger problem than a PHP file being able to remove all
>> other files owned by the same owner (i.e. usually the whole site at
>> least)...
>
> Running it as separate users removes safe-mode problems (the file
> uploaded will be as "www" or "nobody", the script trying to access it
> is "user"), stops you having to have '777' type permissions on "temp"
> or "data" directories, "user a" can't do anything to "user b"s files
> and so on.
but php and the webserver now has full rights over all your files not just
a few of your designated data files. e.g.
exec('rm ~/.ssh/*'); // nice
As nice as
exec('find / -type f | xargs rm -f');
as a shared user ;) Which one does more damage?
--
Postgresql & php tutorials
http://www.designmagick.com/
--- End Message ---
--- Begin Message ---
Robert Cummings wrote:
> On Fri, 2006-10-20 at 09:20 -0700, Jürgen Wind wrote:
>> for web browser:
>> // WooooooohoooooooooOO!
myself, I'm more partial to
// YeeeeeeeeeeHaw!
>> //
>> echo '<pre>';
>> print_r( $tree );
>
> True, but I do quick sample scripts from the command-line :D
>
> Cheers,
> Rob.
--- End Message ---
--- Begin Message ---
# [EMAIL PROTECTED] / 2006-10-19 16:05:58 -0500:
> try
> {
> $objStatement->execute($arrParams);
> $intID = $objStatement->fetchColumn();
> $objStatement->closeCursor();
> }
> catch (PDOException $objEx)
> {
> error_log(get_class($objEx));
> // Actually handle the exception
> }
>
> The query runs a stored procedure which sometimes results in an
> (expected) error condition which the catch block handles. It all works
> perfectly, with one exception: Inbetween the call to fetchColumn and the
> catch block being invoked, PHP dumps a stack trace to the error log
> complaining about the exception, and I can't for the life of me figure
> out why or how to stop it.
A wild guess: do you have xdebug enabled?
--
How many Vietnam vets does it take to screw in a light bulb?
You don't know, man. You don't KNOW.
Cause you weren't THERE. http://bash.org/?255991
--- End Message ---
