Default chmod values

Hi there

Im having trouble with my freeBSD/plesk setup...

I designed the website on Red Hat/cPanel and when migrating to my new dedicated server I did make the changes required for the site to work properly.

The problem I'm having now is that unlike my old hosting account... Whenever I upload a folder from my desktop to the server, the default chmod values are 755... however this means that my script cannot write any folders and files on the remote server unless I change the chmod values. my old server defaulted to one where the script COULD access write to the folder, unsure which chmod it was, exactly, though.

The people who are going to be uploading files/folders to the FTP server arent going to know how to chmod and I dont expect them to.

Is there a way of changing the default permissions of the uploaded folder?
Or another work around - is there a way of allowing the user 'Apache' (which php wrongly classes itself as when using FTP commands, even when logged in as the right user)

I have shell access,etc.

I've also been looking into vsFTP ... will using this program help me to organise users and groups, and possibly even the default chmod?

Thanks in advance

you could chown the folder to the user apache..
that should give it write access to the folder.

This is a very insecure default setup. Publicly accessible directories on a web server should always be umasked to 022, which is what you're seeing on the new server (mode 777 minus 022 = 755, basically).

People uploading to the server should be signed in with their accounts into folders in which they have write permissions.

Yes, change the umask of the folder. However, it's set like that for a reason. I'd suggest a better solution would be to take a better look at what you're doing. If you require anonymous users to upload files, perhaps you should database those files instead of placing them on the filesystem

If PHP is running under the web server, it's running as whatever user apache runs as (usually "apache"). For a user to run the script under their own credentials, you'd either need to start apache running under that user (in httpd.conf) or they'd have to actually log into the server and run the script from the shell. In either case, they'd have to have an actual account on the server, not just be a member of your site.

vsftpd will allow you to set up a (quite secure) FTP server that can jail your users into their home accounts - but again, these users have to have actual system accounts, not just have some entry in a MySQL database table somewhere.

the users wont be anonymous, they are hired photographers who I regard as trustworthy

chown will not work for this situation as it will mean I have to administer every photographer's upload, which I'm attempting to avoid.

Ill explain how the system works...

users upload their folder into a directory based upon the current month, eg.
/2006/10/
this directory is october 2006

then they will upload the pictures they took at a particular night, eg.
/2006/10/eventname/

they will then login to the administration panel of the site and start to create thumbnails by
1) creating new directories (**this is where the permission error occurs - i can chmod the created folders to the right permissions using php, just not create them**)
2) save thumbnails into the appropriate directory


-----

Thanks for your i

If they're paid photographers, why not just give them user accounts and put them into a group that owns those folders, then give those folders permissions like 775? If you give them system accounts and set up an FTP server and they can just use any old FTP client to upload their stuff.

Why do they have to manually create thumbnails? Just set up a shell script to do that.

Nothing you're talking about requires opening up the server to the level you're talking about, though setting it up properly may take a little more time than your "old" method.

World writable directory + an insecure form anywhere on the server + some evil persistance = a bad day for you. Chmodding folders to the apache user isn't an answer either because it's usually this user attempting the exploits to begin with. The apache user shouldn't have write access to anything on the server whatsoever if it can be helped.