By baumer1122 on

When uploading images with image.module, they are saved as user:user with file permissions of 600. Apache is running as nobody and therefore can't serve the images for the webpages. Changing permissions on the files to 644 works, but needs to be done manually after each upload which is no bueno.

Server is running suphp for this site.

I have another site on the same server that is not running suphp and files are saved as nobody:nobody as expected, but with permissions of 644.

My hosting company tells me it is a problem with drupal. Are they right? If so, how do I fix it?

⋅ Categories: Drupal 4.6.x

Comments

styro’s picture

styro commented

What's happening is that due to suphp, php and non php requests are running as different users. Currently uploads are via user (PHP) and downloads are via nobody (Apache).

Enabling private downloads will make the requests for files go through PHP and then (hopefully) get the same access rights as the user that uploaded them.

Failing that you could hack the permissions mask of the upload etc module, but I wouldn't recommend that.

--
Anton

baumer1122’s picture

baumer1122 commented

That is a workaround, but I'm trying to get to the source of the problem. Why does one save as 644 and the other save as 600? Do you think it is an issue with drupal or suphp?

styro’s picture

styro commented

If both sites run the same Drupal code, then Drupal probably isn't anything to do with it - it would have to be environmental.

I've never configured suphp, so I don't know how it works - but I imagine a difference could be that each users shell has a different umask setting.

On both sites, you could try checking the output of both PHPs umask as well as the users umask (via a shell command).

--
Anton

baumer1122’s picture

baumer1122 commented

Finally convinced the hosting company it was an issue with suphp.

They changed the umask value in /etc/suphp.conf

I'm a little dissappointed I had to take on the burden of proving it to them when the fix was so straightforward. The suphp.conf file is only 44 lines long! All they had to do was open it.

styro’s picture

styro commented

But IMO if you are using suphp, having permissions of 600 is a good thing for security. It means other users on the server have no access to your files - especially when you consider that they could be using all kinds of insecure scripts on them. Sure you'd need to use private downloads so that the same user account is used for everything, but I prefer private downloads anyway - it allows you to have finer grained access control over them in Drupal.

I don't see private downloads as a workaround - more like a solution.

--
Anton

murz’s picture

murz
Primary language English
Location Yerevan, Armenia
commented

What mask does they set in suphp.conf for setting read to group permissions of created files?
I have using suphp 0.6.2 and try many variants of umask, but noone give me read permissions to group or other :(

My tests:

umask in suphp.conf - permissions of created file
umask=0227 - 400
umask=0447 - 200
umask=0047 - 200
umask=0077 - 600

Does anybody know what mask I must set to give read permissions to group or to other?