Thanks for your reply.
What you say is absolutely true for the standard Apache
install, but is not the case in all situations.
If you chmod 744, then the directory would have to be owned by the user that runs the web server
process (i.e., apache) to work. Since it's unlikely that you can either 1) have the web server
run as "you" (your user account)
This is exactly the situation with my hosting company (dreamhost.com), and many others. Their knowledge base states:
"On DreamHost servers, we have a special feature called suexec
(which stands for "switch user execution") turned on that makes your
CGI scripts on your web site run as though they were run by your user and group!
As a security precaution, suexec REQUIRES that all cgi scripts AND THE DIRECTORIES IN WHICH THEY RESIDE
*NOT* be writable by anyone but the owner user. Otherwise, another user
on your machine could go into the directory, edit your script to do
something, then visit it from the web and they would then have access
as though they were you! Then, they would essentially have full access to your user account, and that's bad!
SO, suexec requires that you change the owner (chown) and change the
group (chgrp) to be your user and group (don't worry, these are the
defaults when you upload
or create a file), AND that you chmod (change permissions) that file
AND THE DIRECTORY it resides in to be not-writable by the world. You
can do this with the
chmod 755 filename.pl
command. You do NOT want to do chmod 777 filename.pl,
even if your scripts' installation instructions tell you to do that.
They don't know that you're installing your script on a server with
Now, most of my experience has been with Perl scripts, but I would imagine that PHP behaves the same way.
>> And finally, the "chmod
777" is given as the "one-line no-brainer" solution, purely to minimize
I can understand this for development/debugging but for a production server it is exposing your moodle/fileupload directory to anybody. It seems that you are saying that it is too difficult to work out what door key to use to gain access, so you are going to throw all the locks away. Sure, it fixes the problem, but creates a gaping security hole.
And also, it isn't the script that is group/others writable. It's just the upload
But this is still a problem - chmod 777 allows anyone to upload any malicious script to the upload directory, and run it with the same permissions as the normal Moodle scripts. Even if it would be difficult to execute scripts, it still allows anybody with some moodle knowledge to browse the upload directory and download or delete anything that they find there.
The only way to prevent this would be to place the upload directory outside the moodle directory tree. The web server could still access it, but it would be inaccessiblke to normal web clients.