By svref on

When users upload files into sites/default/files/, they're created with 600 -rw------- permissions, and they should be created with 644 -rw-r--r-- permissions, because they're created by the web server process (aka unix user nobody), not the owner of the account whose files they are. Unless that owner has super-root powers, they're unable to read those files, which is absurd since they can read them over the web already (for example browse http://your.site.com/sites/default/files/upload.jpg ).

I think this is a bug, and I'm looking for some way to fix it.

⋅ Categories: Drupal 6.x

Comments

styro’s picture

styro commented

Your server has a restrictive umask setting for new files. Drupal just respects the server configuration - eg on my server they are created with 644 permissions.

You can either ask your host to change that, or don't worry about it and live with it. If you live with it but still need to manipulate those files occasionally you can do it through PHP scripts (which run as the web server user) rather than FTP.

--
Anton
New to Drupal? | Troubleshooting FAQ
Example knowledge base built with Drupal

svref’s picture

svref commented

My ISP's response was to create a small sample php test script:
________________________

<?

$ourFileName = "blah/public_html/sites/default/files/testFile.txt";
$ourFileHandle = fopen($ourFileName, 'w') or die("can't open file");
fclose($ourFileHandle);

?>

________________________

I ran it. The file was created 644, not 600. So it is somehow Drupal's choice, and not apache's.

styro’s picture

styro commented

Drupal 5 definitely didn't have 0600 for uploads, things might've have changed in Drupal 6 (I didn't notice you were on Drupal 6 before). On all my Drupal 5 sites files are either 0644 or 0664.

From my understanding PHP file uploads are saved into a temp directory (by PHP itself) and then moved/copied into their final location (by the PHP script eg Drupal). Note this is a different process that just creating a file directly like your code above does. I suspect your files could be picking up their 0600 perms from the temporary directory rather than Drupal actually setting anything to 0600.

A quick look at some code on Drupal 5:

http://api.drupal.org/api/function/file_save_upload/5 calls
http://api.drupal.org/api/function/file_check_upload/5 to move it from the PHP upload directory to the Drupal temp directory, then filesave_upload() calls
http://api.drupal.org/api/function/file_move/5 which then calls
http://api.drupal.org/api/function/file_copy/5 which actually does the copy from the Drupal temp dir to the Drupal files dir and then chmods the file to 0664

Looking at Drupal 6:

http://api.drupal.org/api/function/file_save_upload/6 works quite differently (although file_move() and file_copy() still look the same they don't seem to be used for this anymore). I don't really see any chmodding going on.

I don't know anything about the background behind the changes though and whether this new behaviour is by design or not.

--
Anton
New to Drupal? | Troubleshooting FAQ
Example knowledge base built with Drupal

svref’s picture

svref commented

Can we zoom out a bit and talk about unix file permissions a bit more? I have the problem that Drupal documentation is very keen on me creating backups, but creates lots of files as user "nobody". I'm not that user, so when I restore backups, they are created as user "cartky". If an old directory was nobody.nobody 744, then when it's untarred from the backup it will be dave.dave 744, drupal can't access it or write it, and chaos ensues.

If I were root I could solve this by calling tar with "--preserve-ownership". But I'm not.

My ad-hoc solution: running around chmoding those directories world-writable, which I'm pretty sure is bad on a multi-user system.

What do you think? Is there a better way?