[PAYH] permissions for inter-server FTPs

[#1]

One of my websites uses FTP* to transfer a file from the home pages webspace to the CGI webspace, update it, and then write it back.
I have just moved the CGI part to Plesk  -  and the 'read from home pages' transfer fell over with a permissions error on the file being written to on the Plesk side.
On CGI, a permission of 640 (owner RW-; user/group R--; everyone ---) works fine but this is insufficient on Plesk.
Plesk needs a 666 (owner RW-; user/group RW-; everyone RW-) for this to work.
Anyone any ideas why pls?
It also makes me wonder what other 'permissions' timebombs I need to look out for ...

* passive FTP initiated from PHP (normal FTP didn't work with CGI)

[#2]

I can't help with your question but can add to the permissions worries. I'm trialling a Joomla site and have had a ton of fun trying to get permissions working right. I'm now finding that some components that upload images to the site can't function properly with the PAYH service. The scripts happily upload the image to the correct location but assigns 600 permissions to the file (RW for www-data user, nothing for everyone else) which means any visitor to the site can't access the image. Using the same component with a different host assigns the file 644 permissions giving read permission for group and everyone which of course works correctly.
It strikes me that setup of the PAYH system is too tight and making things overly hard to get working, or I'm just missing something very obvious!

[#3]

Rant begins  :
PHP on PAYH is a) version 5.2.0 rather than version 4.3.10 on ccgi, and b) running as an Apache2 module rather than CGI.
When run as CGI or FastCGI, PHP scripts and packages based on PHP can run as user. When run as mod_php5, PHP will run as Apache (www-data). So, on PAYH, if you need to give PHP or a PHP-based package access to user-generated files, they will need to be set rw for other/everyone. To minimise the necessary permissions, create files (and separate folders) via PHP.
On the plus side, mod_php5 is fast and you can use htaccess for authentication and to modify some flags and values. From Plusnet’s point of view, it’s also highly scaleable.
However... with PHP running as Apache, open_basedir has to be set to secure vhosts from each other. Unfortunately, some useful PHP functions and features need to be disabled under this condition.
So, we have two problems/opportunities: 1) user management of files and permissions is more complicated, 2) we’re missing some useful/necessary functionality.
For some of us, these opportunities could prove insurmountable.
My current feeling is that I will use the bundled hosting for some of my sites, but wouldn’t pay for more bandwidth on this platform. When the old server goes, my main site will have to leave Plus.
Plusnet could help us out here. It is possible to run parallel versions of PHP (CGI or FastCGI alongside mod_php5), differentiated by location or extension. Alternatively, there are multi-processing modules for Apache that will run Apache itself (not just PHP or other interpreters) as separate users. mpm-itk is even bundled with Debian. The main downside is a performance hit, particularly for static pages; mpm-peruser performs better but requires more active management (and is possibly still too experimental for Plusnet to consider).
There are security pros and cons associated with the various solutions. I feel they close more holes than they open.
Perl is running as user. It would be really useful if PHP (or even Apache) did too.
Rant ends  .
Sorry if that was long.
Gabe

[#4]

Gabe, thanks for another reply on this subject, you clearly know a lot more about LAMP than I do but I do get quite a bit of what you're saying. Sadly I think I'm in the same boat as you, when the CGI system gets turned off, it's time to move as things are too restrictive.
Perhaps Kev or another Plusnet staffer could get involved with the thread? Better still do some actual real world testing using the hosting with some of the 2.0 web development packages out there (Joomla, Drupal etc)? Once started it will be rapidly obvious why the current permissions/default user setup just doesn't work. At this point it should become quickly apparent why the PAYH hosting is IMHO fatally flawed.