From vegard at svanberg.no  Tue Sep  2 10:35:30 2008
From: vegard at svanberg.no (Vegard Svanberg)
Date: Tue, 2 Sep 2008 10:35:30 +0200
Subject: [suPHP] suPHP and symlinks revisited
Message-ID: <20080902083530.GK10869@svanberg.no>

I've seen this issue been up for debate before, but browsing through the
archives, I'm a bit unsure what common practice and solutions are. 

Imagine the following scenario:

User 1: /home/user1/html (owned by "user1")
User 2: /home/user2/html (owned by "user2")
Common (shared) code: /usr/local/commoncode (owned by "commoncode")

Symlinks:

/home/user1/html/commoncode -> /usr/local/commoncode
/home/user2/html/commoncode -> /usr/local/commoncode

(I've tried owning the symlinks as "userX", "commoncode" and "root".)

suPHP 0.6.2 will execute this, 0.6.3 won't ("directory /home/user1/html
not owned by commoncode"). I can't see any immediate solutions to this.

Any suggestions?

-- 
Vegard Svanberg <vegard at svanberg.no> [*Takapa at IRC (EFnet)]



From FractalizeR at yandex.ru  Tue Sep  2 12:15:02 2008
From: FractalizeR at yandex.ru (Vladislav Rastrusny)
Date: Tue, 2 Sep 2008 14:15:02 +0400
Subject: [suPHP] suPHP and symlinks revisited
In-Reply-To: <20080902083530.GK10869@svanberg.no>
References: <20080902083530.GK10869@svanberg.no>
Message-ID: <816f264c0809020315i273bbdc7qe1121a46cad52a96@mail.gmail.com>

I suppose there is no solution. Your situation seem to be considered a
security whole in 0.6.2 and fixed in 0.6.3 (check news on
www.suphp.org)

2008/9/2 Vegard Svanberg <vegard at svanberg.no>:
> I've seen this issue been up for debate before, but browsing through the
> archives, I'm a bit unsure what common practice and solutions are.
>
> Imagine the following scenario:
>
> User 1: /home/user1/html (owned by "user1")
> User 2: /home/user2/html (owned by "user2")
> Common (shared) code: /usr/local/commoncode (owned by "commoncode")
>
> Symlinks:
>
> /home/user1/html/commoncode -> /usr/local/commoncode
> /home/user2/html/commoncode -> /usr/local/commoncode
>
> (I've tried owning the symlinks as "userX", "commoncode" and "root".)
>
> suPHP 0.6.2 will execute this, 0.6.3 won't ("directory /home/user1/html
> not owned by commoncode"). I can't see any immediate solutions to this.
>
> Any suggestions?
>
> --
> Vegard Svanberg <vegard at svanberg.no> [*Takapa at IRC (EFnet)]
>
>
> _______________________________________________
> suPHP mailing list
> suPHP at lists.marsching.biz
> http://lists.marsching.com/mailman/listinfo/suphp
>


From voron at amhost.net  Mon Sep 22 19:37:32 2008
From: voron at amhost.net (Alex Vorona)
Date: Mon, 22 Sep 2008 20:37:32 +0300
Subject: [suPHP] suphp force mode on apache 1.3
Message-ID: <48D7D7DC.3060303@amhost.net>

Hello,

Does anyone tried this?

 From http://www.suphp.org/Documentation-Installation.en.html
================================================================
MODE has to be one of:
"owner": Run scripts with owner UID/GID
"force": Run scripts with UID/GID specified in Apache configuration (only supported when using Apach 2)
"paranoid": Run scripts with owner UID/GID but also check if they match the UID/GID specified in the 
Apache configuration
================================================================
But we have no problems with suPHP 0.6.3, php 5.2.6, apache 1.3.41 and --with-setid-mode=force.
Scripts are running with effective user:group as was set in suPHP_UserGroup directive of current 
virtual host, regardless of actual owner:group of php-file.

Can someone confirm this too ?

Thanks,
Alex


From suphp at jdc.parodius.com  Mon Sep 22 20:11:45 2008
From: suphp at jdc.parodius.com (Jeremy Chadwick)
Date: Mon, 22 Sep 2008 11:11:45 -0700
Subject: [suPHP] suphp force mode on apache 1.3
In-Reply-To: <48D7D7DC.3060303@amhost.net>
References: <48D7D7DC.3060303@amhost.net>
Message-ID: <20080922181145.GA32248@icarus.home.lan>

On Mon, Sep 22, 2008 at 08:37:32PM +0300, Alex Vorona wrote:
> Does anyone tried this?
> 
>  From http://www.suphp.org/Documentation-Installation.en.html
> ================================================================
> MODE has to be one of:
> "owner": Run scripts with owner UID/GID
> "force": Run scripts with UID/GID specified in Apache configuration (only supported when using Apach 2)
> "paranoid": Run scripts with owner UID/GID but also check if they match the UID/GID specified in the 
> Apache configuration
> ================================================================
> But we have no problems with suPHP 0.6.3, php 5.2.6, apache 1.3.41 and --with-setid-mode=force.
> Scripts are running with effective user:group as was set in suPHP_UserGroup directive of current 
> virtual host, regardless of actual owner:group of php-file.
> 
> Can someone confirm this too ?

I believe "force" mode is supported on Apache 1.3.x and 2.x both, and
the documentation is simply outdated.  I've looked at the source code
and I see no reason why force and paranoid shouldn't work under 1.3.

-- 
| Jeremy Chadwick                                jdc at parodius.com |
| Parodius Networking                       http://www.parodius.com/ |
| UNIX Systems Administrator                  Mountain View, CA, USA |
| Making life hard for others since 1977.              PGP: 4BD6C0CB |


From olriss at sistemenginarlari.com  Wed Sep 24 14:49:41 2008
From: olriss at sistemenginarlari.com (olriss)
Date: Wed, 24 Sep 2008 15:49:41 +0300
Subject: [suPHP] suphp uploaded file permissions
Message-ID: <48DA3765.1090101@sistemenginarlari.com>

I installed libapache2-mod-suphp-0.6.2-1+etch0,but have some problems.
when I create new file with php code it's permissions seems ok.(644)
but uploaded files with same way is not.(600)

Lots of people says that file upload operation is not related with suphp.

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.



From fili at fili.nl  Wed Sep 24 16:33:08 2008
From: fili at fili.nl (Fili)
Date: Wed, 24 Sep 2008 16:33:08 +0200
Subject: [suPHP] suphp uploaded file permissions
In-Reply-To: <48DA3765.1090101@sistemenginarlari.com>
References: <48DA3765.1090101@sistemenginarlari.com>
Message-ID: <48DA4FA4.9040804@fili.nl>

olriss wrote:
> I installed libapache2-mod-suphp-0.6.2-1+etch0,but have some problems.
> when I create new file with php code it's permissions seems ok.(644)
> but uploaded files with same way is not.(600)
>
> Lots of people says that file upload operation is not related with suphp.
>
>   

This behaviour is adjustable by the umask setting in /etc/suphp/suphp.conf.
Change umask=0077 to umask=0022 and new files will be created as 644.

-Fili


From johannes.nohl at gmail.com  Wed Sep 24 19:23:23 2008
From: johannes.nohl at gmail.com (Johannes Nohl)
Date: Wed, 24 Sep 2008 19:23:23 +0200
Subject: [suPHP] suphp uploaded file permissions
In-Reply-To: <48DA3765.1090101@sistemenginarlari.com>
References: <48DA3765.1090101@sistemenginarlari.com>
Message-ID: <33d293f80809241023t41bde86ex8e91f0131bf72d42@mail.gmail.com>

> I installed libapache2-mod-suphp-0.6.2-1+etch0,but have some problems.
> when I create new file with php code it's permissions seems ok.(644)
> but uploaded files with same way is not.(600)

How files are created is managed by umask. Your php.ini is set to umask = 0644.

> Lots of people says that file upload operation is not related with suphp.

Right. It depends on how you load up. Let's say by ftp then you have
to adjust the umask setting in your ftpd config. Or if users create
new files using ssh you need to adjust the shells umask.


I'd prefer to have a script that will adjust files automatically. Did
anyone wrote something like it? Could be written in php. It
recursively go through the files (htdocs and under) and chmod them
depending on their suffix. Additionally there need to be a mechanism
that prevent unwished changes. Please post it here if you've done
already.


Johannes


From olriss at sistemenginarlari.com  Wed Sep 24 21:52:48 2008
From: olriss at sistemenginarlari.com (olriss)
Date: Wed, 24 Sep 2008 22:52:48 +0300
Subject: [suPHP] suphp uploaded file permissions
In-Reply-To: <48DA4FA4.9040804@fili.nl>
References: <48DA3765.1090101@sistemenginarlari.com> <48DA4FA4.9040804@fili.nl>
Message-ID: <48DA9A90.70707@sistemenginarlari.com>

my umask setting is 0022 already.actually it works.it tested with fopen 
function.but uploaded files still have 600
I didn't understand that difference between mod_php and 
suphp.Because,before install suphp,the files can be uploaded with world 
readable permissions,or umask settings works for uploaded files too.but 
now it's not.

eventually,apache can't read these files,photos,zips etc.

If I can't find any solutions,I will write a cron job like ;
find /var/www/vhosts/ -type f -exec chmod 644 {} \; -print or,
find /var/www/vhosts/ -type f -perm 600 -exec chmod 644 {} \; -print



Fili wrote:
> olriss wrote:
>> I installed libapache2-mod-suphp-0.6.2-1+etch0,but have some problems.
>> when I create new file with php code it's permissions seems ok.(644)
>> but uploaded files with same way is not.(600)
>>
>> Lots of people says that file upload operation is not related with 
>> suphp.
>>
>>   
>
> This behaviour is adjustable by the umask setting in 
> /etc/suphp/suphp.conf.
> Change umask=0077 to umask=0022 and new files will be created as 644.
>
> -Fili
>



From olriss at sistemenginarlari.com  Wed Sep 24 21:53:27 2008
From: olriss at sistemenginarlari.com (olriss)
Date: Wed, 24 Sep 2008 22:53:27 +0300
Subject: [suPHP] suphp uploaded file permissions
In-Reply-To: <48DA9A90.70707@sistemenginarlari.com>
References: <48DA3765.1090101@sistemenginarlari.com> <48DA4FA4.9040804@fili.nl>
	<48DA9A90.70707@sistemenginarlari.com>
Message-ID: <48DA9AB7.8040402@sistemenginarlari.com>

olriss wrote:
> my umask setting is 0022 already.actually it works.it tested with 
> fopen function.but uploaded files still have 600
> I didn't understand that difference between mod_php and 
> suphp.Because,before install suphp,the files can be uploaded with 
> world readable permissions,or umask settings works for uploaded files 
> too.but now it's not.
>
> eventually,apache can't read these files,photos,zips etc.
>
> If I can't find any solutions,I will write a cron job like ;
> find /var/www/vhosts/ -type f -exec chmod 644 {} \; -print or,
> find /var/www/vhosts/ -type f -perm 600 -exec chmod 644 {} \; -print
>
>
>
> Fili wrote:
>> olriss wrote:
>>> I installed libapache2-mod-suphp-0.6.2-1+etch0,but have some problems.
>>> when I create new file with php code it's permissions seems ok.(644)
>>> but uploaded files with same way is not.(600)
>>>
>>> Lots of people says that file upload operation is not related with 
>>> suphp.
>>>
>>>   
>>
>> This behaviour is adjustable by the umask setting in 
>> /etc/suphp/suphp.conf.
>> Change umask=0077 to umask=0022 and new files will be created as 644.
>>
>> -Fili
>>
>
>


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.



From jdtysko at bcsengineering.com  Wed Sep 24 23:13:54 2008
From: jdtysko at bcsengineering.com (J.D. Tysko)
Date: Wed, 24 Sep 2008 17:13:54 -0400
Subject: [suPHP] SuPHP recursive forking
Message-ID: <48DAAD92.6060007@bcsengineering.com>

Hi,

We have a PHP application which needs to exec off another PHP process. 
The problem is, is that when we use a command with "php" in it,
recursive forking is started.

We installed this software on a server running CPanel running SuPHP.
when we tested the software we had a catastrophic failure where
thousands of processes were being spawned off.  Through an extensive
debugging process, we were able narrow the issue down to SuPHP.  I have
attached a test script displaying this behavior.  When the script is run
from the command line, It functions correctly.  When it is run as a CGI
script on the web, it fails 2 ways: If you click the "Go POST" button,
the script runs, but the output in the log file is incorrect, being a
complete http response rather than the php version info. If the "Go GET"
button is clicked, the script will execute once in the browser, then
continue forking itself, outputting the same thing as the post method. 
Our guess is that SuPHP revisits the GET command which causes a
recursive loop.  Can you please advise us how we can get this working?

Thanks,  
J.D. Tysko
Software Engineer
BCS Engineering
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test_suphp.php
Type: application/x-php
Size: 853 bytes
Desc: not available
Url : http://lists.marsching.com/pipermail/suphp/attachments/20080924/623eb5f3/attachment.bin 

From sebastian at marsching.com  Thu Sep 25 12:38:08 2008
From: sebastian at marsching.com (Sebastian Marsching)
Date: Thu, 25 Sep 2008 12:38:08 +0200
Subject: [suPHP] SuPHP recursive forking
In-Reply-To: <48DAAD92.6060007@bcsengineering.com>
References: <48DAAD92.6060007@bcsengineering.com>
Message-ID: <48DB6A10.9070304@marsching.com>

Hi,

J.D. Tysko schrieb:

> We have a PHP application which needs to exec off another PHP process. 
> The problem is, is that when we use a command with "php" in it,
> recursive forking is started.

When PHP is called and the CGI specific environment variables (like 
PATH_INFO, PATH_TRANSLATED, etc.) are set, PHP executes the script 
specified by this environment variables and not the script specified on 
the command line.

Therefore after forking, before executing another instance of PHP you 
have to unset all the CGI environment variables in order to make PHP 
execute the right script.

Regards
Sebastian



From sebastian at marsching.com  Thu Sep 25 12:39:43 2008
From: sebastian at marsching.com (Sebastian Marsching)
Date: Thu, 25 Sep 2008 12:39:43 +0200
Subject: [suPHP] suphp force mode on apache 1.3
In-Reply-To: <20080922181145.GA32248@icarus.home.lan>
References: <48D7D7DC.3060303@amhost.net>
	<20080922181145.GA32248@icarus.home.lan>
Message-ID: <48DB6A6F.4060402@marsching.com>

Hi,

Jeremy Chadwick schrieb:

> I believe "force" mode is supported on Apache 1.3.x and 2.x both, and
> the documentation is simply outdated.  I've looked at the source code
> and I see no reason why force and paranoid shouldn't work under 1.3.

You are right, the documentation is just outdated regarding this point.
I just fixed the documentation in SVN.

Regards
Sebastian


From brockn at gmail.com  Thu Sep 25 16:29:32 2008
From: brockn at gmail.com (Brock Noland)
Date: Thu, 25 Sep 2008 09:29:32 -0500
Subject: [suPHP] SuPHP recursive forking
In-Reply-To: <48DB6A10.9070304@marsching.com>
References: <48DAAD92.6060007@bcsengineering.com>
	<48DB6A10.9070304@marsching.com>
Message-ID: <741dcbb80809250729k23c7e987m2c0b54f25bd0b79c@mail.gmail.com>

On Thu, Sep 25, 2008 at 5:38 AM, Sebastian Marsching <
sebastian at marsching.com> wrote:

> Hi,
>
> J.D. Tysko schrieb:
>
> > We have a PHP application which needs to exec off another PHP process.
> > The problem is, is that when we use a command with "php" in it,
> > recursive forking is started.
>
> When PHP is called and the CGI specific environment variables (like
> PATH_INFO, PATH_TRANSLATED, etc.) are set, PHP executes the script
> specified by this environment variables and not the script specified on
> the command line.
>
> Therefore after forking, before executing another instance of PHP you
> have to unset all the CGI environment variables in order to make PHP
> execute the right script.


I would use env -i:

$ printenv | wc -l
28
$ env -i printenv | wc -l
0

Brock
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.marsching.com/pipermail/suphp/attachments/20080925/10944550/attachment.htm 

From jdtysko at bcsengineering.com  Thu Sep 25 15:38:44 2008
From: jdtysko at bcsengineering.com (J.D. Tysko)
Date: Thu, 25 Sep 2008 09:38:44 -0400
Subject: [suPHP] SuPHP recursive forking
In-Reply-To: <48DB6A10.9070304@marsching.com>
References: <48DAAD92.6060007@bcsengineering.com>
	<48DB6A10.9070304@marsching.com>
Message-ID: <48DB9464.2000609@bcsengineering.com>

Hi, thanks for your reply.

I think I understand what you're saying, but I'm a little unclear how I
can unset those CGI specific variables *after* forking since I'm using
system() and like commands which do the fork on their own.  The only
thing I can think of is using the "temporary" environment variables
(like: system("PATH_INFO= PATH_TRANSLATED php --version");) but that
could end up being quite a long command line.  Is there another way and
can you give a code example?

Thanks,
J.D. Tysko
Software Engineer
BCS Engineering
>
> When PHP is called and the CGI specific environment variables (like
> PATH_INFO, PATH_TRANSLATED, etc.) are set, PHP executes the script
> specified by this environment variables and not the script specified
> on the command line.
>
> Therefore after forking, before executing another instance of PHP you
> have to unset all the CGI environment variables in order to make PHP
> execute the right script.



From suphp at jdc.parodius.com  Fri Sep 26 13:17:52 2008
From: suphp at jdc.parodius.com (Jeremy Chadwick)
Date: Fri, 26 Sep 2008 04:17:52 -0700
Subject: [suPHP] SuPHP recursive forking
In-Reply-To: <48DB9464.2000609@bcsengineering.com>
References: <48DAAD92.6060007@bcsengineering.com>
	<48DB6A10.9070304@marsching.com>
	<48DB9464.2000609@bcsengineering.com>
Message-ID: <20080926111752.GA23236@icarus.home.lan>

Try using putenv() in your PHP scripts.  Note that to unset an
environment variable, you use putenv("VAR"), not putenv("VAR=").
(Because apparently the PHP folks would rather implement something
bizarre than just use unsetenv(3)).

-- 
| Jeremy Chadwick                                jdc at parodius.com |
| Parodius Networking                       http://www.parodius.com/ |
| UNIX Systems Administrator                  Mountain View, CA, USA |
| Making life hard for others since 1977.              PGP: 4BD6C0CB |

On Thu, Sep 25, 2008 at 09:38:44AM -0400, J.D. Tysko wrote:
> Hi, thanks for your reply.
> 
> I think I understand what you're saying, but I'm a little unclear how I
> can unset those CGI specific variables *after* forking since I'm using
> system() and like commands which do the fork on their own.  The only
> thing I can think of is using the "temporary" environment variables
> (like: system("PATH_INFO= PATH_TRANSLATED php --version");) but that
> could end up being quite a long command line.  Is there another way and
> can you give a code example?
> 
> Thanks,
> J.D. Tysko
> Software Engineer
> BCS Engineering
> >
> > When PHP is called and the CGI specific environment variables (like
> > PATH_INFO, PATH_TRANSLATED, etc.) are set, PHP executes the script
> > specified by this environment variables and not the script specified
> > on the command line.
> >
> > Therefore after forking, before executing another instance of PHP you
> > have to unset all the CGI environment variables in order to make PHP
> > execute the right script.
> 
> 
> _______________________________________________
> suPHP mailing list
> suPHP at lists.marsching.biz
> http://lists.marsching.com/mailman/listinfo/suphp


From jd at cpanel.net  Fri Sep 26 17:20:09 2008
From: jd at cpanel.net (John Lightsey)
Date: Fri, 26 Sep 2008 10:20:09 -0500
Subject: [suPHP] SuPHP recursive forking
In-Reply-To: <48DAAD92.6060007@bcsengineering.com>
References: <48DAAD92.6060007@bcsengineering.com>
Message-ID: <9D7E0600-2E98-47CC-903D-45801034DD71@cpanel.net>


On Sep 24, 2008, at 4:13 PM, J.D. Tysko wrote:

> Hi,
>
> We have a PHP application which needs to exec off another PHP process.
> The problem is, is that when we use a command with "php" in it,
> recursive forking is started.
>
> We installed this software on a server running CPanel running SuPHP.
> when we tested the software we had a catastrophic failure where
> thousands of processes were being spawned off.  Through an extensive
> debugging process, we were able narrow the issue down to SuPHP.  I  
> have
> attached a test script displaying this behavior.  When the script is  
> run
> from the command line, It functions correctly.  When it is run as a  
> CGI
> script on the web, it fails 2 ways: If you click the "Go POST" button,
> the script runs, but the output in the log file is incorrect, being a
> complete http response rather than the php version info. If the "Go  
> GET"
> button is clicked, the script will execute once in the browser, then
> continue forking itself, outputting the same thing as the post method.
> Our guess is that SuPHP revisits the GET command which causes a
> recursive loop.  Can you please advise us how we can get this working?

This problem is somewhat cPanel specific because of the configuration  
of mod_suphp and the way PHP is installed on cPanel systems.

On a cPanel machine /usr/bin/php is the PHP CGI binary and /usr/local/ 
bin/php is the PHP CLI binary.  In /opt/suphp/etc/suphp.conf the  
env_path is set to /bin:/usr/bin.

So...  If you're running a PHP script via mod_suphp on a cPanel system  
and you just exec('php -v'), it's going to find the PHP CGI binary  
instead of the PHP CLI binary.  As others have mentioned, the PHP CGI  
binary doesn't care about the arguments you supply if it see  
SCRIPT_FILENAME set in the environment.  This goes beyond mod_suphp as  
well.  BSD systems have a reversed path with /usr/bin/ searched  
before /usr/local/bin/, so even using libphp you might run into the  
same issue on some systems.

The best fix is to always supply the full path to the PHP CLI  
interpreter.

You can also clean up the environment by deleting DOCUMENT_ROOT,  
SERVER_SOFTWARE, SCRIPT_FILENAME and probably a few others.  Even with  
those deleted the PHP CGI binary behaves differently than the CLI  
binary.  I've seen quite a few systems where the CGI binary will  
generate fatal memory errors after the PHP script has been fully  
executed.  Better to use the CLI binary if possible.

You can also explicitly set the PATH environmental variable in your  
script.

You could also set env_path in suphp.conf to match the standard system  
PATH /usr/local/bin:/bin:/usr/bin

J.D.



From jani.ollikainen at pronetko.fi  Fri Sep 26 17:40:44 2008
From: jani.ollikainen at pronetko.fi (Jani Ollikainen)
Date: Fri, 26 Sep 2008 18:40:44 +0300
Subject: [suPHP] SuPHP recursive forking
In-Reply-To: <9D7E0600-2E98-47CC-903D-45801034DD71@cpanel.net>
References: <48DAAD92.6060007@bcsengineering.com>
	<9D7E0600-2E98-47CC-903D-45801034DD71@cpanel.net>
Message-ID: <20080926154043.GD24529@purkki.org>

On Fri, Sep 26, 2008 at 10:20:09AM -0500, John Lightsey wrote:
> On a cPanel machine /usr/bin/php is the PHP CGI binary and /usr/local/ 
> bin/php is the PHP CLI binary.  In /opt/suphp/etc/suphp.conf the  
> env_path is set to /bin:/usr/bin.

In smart distributions php is the cli binary and php-cgi is the cgi
binary..

If cPanel uses both cgi and cli with the name php, that's just nasty.
I think you should try to fix cPanel to have smarter naming of php binaries.

-- 
 Jani Ollikainen


From csoto at sia-solutions.com  Fri Sep 26 21:05:27 2008
From: csoto at sia-solutions.com (Carlos C Soto)
Date: Fri, 26 Sep 2008 14:05:27 -0500
Subject: [suPHP] suphp uploaded file permissions
In-Reply-To: <33d293f80809241023t41bde86ex8e91f0131bf72d42@mail.gmail.com>
References: <48DA3765.1090101@sistemenginarlari.com>
	<33d293f80809241023t41bde86ex8e91f0131bf72d42@mail.gmail.com>
Message-ID: <48DD3277.80502@sia-solutions.com>

Johannes Nohl wrote:
>> I installed libapache2-mod-suphp-0.6.2-1+etch0,but have some problems.
>> when I create new file with php code it's permissions seems ok.(644)
>> but uploaded files with same way is not.(600)
>
> How files are created is managed by umask. Your php.ini is set to umask = 0644.

You must try to setup the right permissions.
It is part of your application behavior and should be handled by your 
application at the time of create/upload/edit the file.
Actually, I have seen several applications with this as configurable.
As PHP process run as the user it apply the same right to change the 
permissions.

>
>> Lots of people says that file upload operation is not related with suphp.
>
> Right. It depends on how you load up. Let's say by ftp then you have
> to adjust the umask setting in your ftpd config. Or if users create
> new files using ssh you need to adjust the shells umask.
>
>
> I'd prefer to have a script that will adjust files automatically. Did
> anyone wrote something like it? Could be written in php. It
> recursively go through the files (htdocs and under) and chmod them
> depending on their suffix. Additionally there need to be a mechanism
> that prevent unwished changes. Please post it here if you've done
> already.
>

How about this? I'm using ACL under Debian Stable.

#!/bin/bash
####################################
#/usr/local/sbin/admin-repair-public_html
####################################

# Chech the executor is root
if [ "`whoami`" != "root" ]; then
  echo "You must be root to execute this script"
  exit 0
fi

# Ask for the username
echo -n "Username: "
read username
if [ -z "$username" ]; then
  echo "ERROR: Must provide a username"
  exit 0
fi

# Checking for the user
if [ -z "`grep ^${username}: /etc/passwd`" ]; then
  echo "ERROR: The user does not exists"
  exit 0
else
  if [ ! -d "/home/${username}/public_html" ]; then
    echo "ERROR: The user exists but the public_html directory doesn't"
    exit 0
  fi
fi

# Make owner of his files and acces to
chmodrecursive /home/${username} 750 640 ${username} > /dev/null
setfacl -m u:www-data:rx /home/${username}
setfacl -R -m u:www-data:rx /home/${username}/public_html
setfacl -d -R -m u:www-data:rx /home/${username}/public_html
chmodrecursive /home/${username} 750 640 ${username} > /dev/null


#!/bin/bash
####################################
#/usr/local/bin/chmodrecursive
####################################

DEBUG=""
IFS=$'\n';


function udf_change {
  chown $4:$4 "${1}" -R
  lstItem=`find "${1}"`
  for iItem in ${lstItem} ; do
    if [ "${iItem}" ]; then
      if [ "${DEBUG}" ] ; then echo -n "${iItem}: " ; fi
      if [ -L "${iItem}" ]; then
        if [ "${DEBUG}" ] ; then echo -n "link" ; fi
      elif [ -d "${iItem}" ]; then
        chmod $2 "${iItem}"
        if [ "${DEBUG}" ] ; then echo -n "dir" ; fi
      else
        chmod $3 "${iItem}"
        if [ "${DEBUG}" ] ; then echo -n "file" ; fi
      fi
      echo " ."
    fi
  done
}

function udf_syntax {
  echo "$0 directory chmod-dir chmod-file owner"
  exit 1
}

if [ -z "${1}" -o -z "${2}" -o -z "${3}"  -o -z "${4}" ]; then
  udf_syntax
fi

udf_change "${1}" "${2}" "${3}" "${4}"

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.marsching.com/pipermail/suphp/attachments/20080926/a7927bf7/attachment.htm 

From jdtysko at bcsengineering.com  Fri Sep 26 15:56:50 2008
From: jdtysko at bcsengineering.com (J.D. Tysko)
Date: Fri, 26 Sep 2008 09:56:50 -0400
Subject: [suPHP] SuPHP recursive forking
In-Reply-To: <20080926111752.GA23236@icarus.home.lan>
References: <48DAAD92.6060007@bcsengineering.com>
	<48DB6A10.9070304@marsching.com>
	<48DB9464.2000609@bcsengineering.com>
	<20080926111752.GA23236@icarus.home.lan>
Message-ID: <48DCEA22.4080304@bcsengineering.com>

I used env -i with spectacular results.  It worked perfectly, with the
exception of resetting the environment (so me of which is kind of
needed).  Next I thought I could just modify the environment like Jeremy
said, and I have a small snippet where I use something like:
    $tmp = getenv("VAR");
    putenv("VAR");
    shell_exec(...);
    putenv("VAR=".$tmp);

But with an array to hold all of the saved vars, but I can't seem to
find the right environment variables to unset.  Can someone give me a
list of CGI variables which should be unset to allow PHP to work as a
CLI version, but not mess up anything else?

Thanks,
J.D. Tysko
Software Engineer
BCS Engineering


Jeremy Chadwick wrote:
> Try using putenv() in your PHP scripts.  Note that to unset an
> environment variable, you use putenv("VAR"), not putenv("VAR=").
> (Because apparently the PHP folks would rather implement something
> bizarre than just use unsetenv(3)).
>   


From suphp at jdc.parodius.com  Sat Sep 27 04:41:32 2008
From: suphp at jdc.parodius.com (Jeremy Chadwick)
Date: Fri, 26 Sep 2008 19:41:32 -0700
Subject: [suPHP] SuPHP recursive forking
In-Reply-To: <20080926154043.GD24529@purkki.org>
References: <48DAAD92.6060007@bcsengineering.com>
	<9D7E0600-2E98-47CC-903D-45801034DD71@cpanel.net>
	<20080926154043.GD24529@purkki.org>
Message-ID: <20080927024132.GA40097@icarus.home.lan>

On Fri, Sep 26, 2008 at 06:40:44PM +0300, Jani Ollikainen wrote:
> On Fri, Sep 26, 2008 at 10:20:09AM -0500, John Lightsey wrote:
> > On a cPanel machine /usr/bin/php is the PHP CGI binary and /usr/local/ 
> > bin/php is the PHP CLI binary.  In /opt/suphp/etc/suphp.conf the  
> > env_path is set to /bin:/usr/bin.
> 
> In smart distributions php is the cli binary and php-cgi is the cgi
> binary..

Agreed/correct.

On FreeBSD, the CLI is called /usr/local/bin/php, and the CGI is
called /usr/local/bin/php5-cgi.  If an administrator doesn't know
the difference, then they should be passing off such administrative
tasks onto someone who does.

> If cPanel uses both cgi and cli with the name php, that's just nasty.
> I think you should try to fix cPanel to have smarter naming of php binaries.

Agreed.

-- 
| Jeremy Chadwick                                jdc at parodius.com |
| Parodius Networking                       http://www.parodius.com/ |
| UNIX Systems Administrator                  Mountain View, CA, USA |
| Making life hard for others since 1977.              PGP: 4BD6C0CB |



From jd at cpanel.net  Mon Sep 29 17:10:04 2008
From: jd at cpanel.net (John Lightsey)
Date: Mon, 29 Sep 2008 10:10:04 -0500
Subject: [suPHP] SuPHP recursive forking
In-Reply-To: <20080927024132.GA40097@icarus.home.lan>
References: <48DAAD92.6060007@bcsengineering.com>
	<9D7E0600-2E98-47CC-903D-45801034DD71@cpanel.net>
	<20080926154043.GD24529@purkki.org>
	<20080927024132.GA40097@icarus.home.lan>
Message-ID: <D359F8DC-AF37-4DC2-B1C0-E00FBADAF7DD@cpanel.net>

On Sep 26, 2008, at 9:41 PM, Jeremy Chadwick wrote:

> On Fri, Sep 26, 2008 at 06:40:44PM +0300, Jani Ollikainen wrote:
>> On Fri, Sep 26, 2008 at 10:20:09AM -0500, John Lightsey wrote:
>>> On a cPanel machine /usr/bin/php is the PHP CGI binary and /usr/ 
>>> local/
>>> bin/php is the PHP CLI binary.  In /opt/suphp/etc/suphp.conf the
>>> env_path is set to /bin:/usr/bin.
>>
>> In smart distributions php is the cli binary and php-cgi is the cgi
>> binary..
>
> Agreed/correct.
>
> On FreeBSD, the CLI is called /usr/local/bin/php, and the CGI is
> called /usr/local/bin/php5-cgi.  If an administrator doesn't know
> the difference, then they should be passing off such administrative
> tasks onto someone who does.

My understanding is that in the past FreeBSD wouldn't allow you to  
install the PHP 4 CLI and CGI binaries simultaneously, so it's still  
possible on an older FreeBSD machine that /usr/local/bin/php is the  
CGI binary.

>
>> If cPanel uses both cgi and cli with the name php, that's just nasty.
>> I think you should try to fix cPanel to have smarter naming of php  
>> binaries.
>
> Agreed.

The way we install it is a legacy issue originally intended to deal  
with PHP4's inability to install the PHP CGI and PHP CLI binaries in  
the same location.  PHP4 installs both the CLI and CGI binaries as  
just "php".  The PHP development team corrected that problem with  
PHP5, but we have many customers who still want to use 4 and have  
applications that are expecting the CGI and CLI binaries to be  
installed in those specific locations.

In the longer run we'd like to get these custom PHP installs out of  
the system paths entirely and just use a symlink for one version of  
the the CLI binary into /usr/bin/php.

If we're handing out blame though, I'd say that the bigger issue is  
that there shouldn't be separate CLI and CGI binaries to begin with.   
PHP has its own legacy problems to deal with though and this seems to  
be one of them.  Of course, deciding that "php" will only refer to the  
CLI binary after years of using it to refer to both the CLI and CGI  
binaries isn't a very safe approach to begin with.  They could have  
called it php-cli with PHP5 to avoid these name collisions.

J.D.