PHP permission mask error

[Rodolfo]

When Chevereto upload images it attempts to create datefolders. Problem is that in some server environments this folder is created with no public permission. This means that he image is there but you can't access to it.

To be honest this is a very new thing that I've noticed in a bunch of OVH machines and so on. Problem is that PHP is messing the folder permissions. When PHP creates a folder using mkdir() the folder is created with the permissions hierarchy of the users who runs PHP (in short, the permissions are wrong).

Since this is a configuration error (most likely a guy made a guide to setup PHP and something was missed..) tell your hosting provider this:

PHP Can't chmod files/directories and that mkdir("some/path", 0755, true) is not setting the permission to 0755.

Workaround
Use "direct" as storage method instead of datefolders.

 

[Zangoose]

When Chevereto upload images it attempts to create datefolders. Problem is that in some server environments this folder is created with no public permission. This means that he image is there but you can't access to it.

To be honest this is a very new thing that I've noticed in a bunch of OVH machines and so on. Problem is that PHP is messing the folder permissions. When PHP creates a folder using mkdir() the folder is created with the permissions hierarchy of the users who runs PHP (in short, the permissions are wrong).

Since this is a configuration error (most likely a guy made a guide to setup PHP and something was missed..) tell your hosting provider this:

Workaround
Use "direct" as storage method instead of datefolders.

I have done this and everything I can think of to do with this also and for some reason, I still cannot access the files.

When I attempt to access the files on the actual desktop (I'm on a Windows Server using the 2012 OS also using IIS) it gives me an "Access to [filedir] was denied" error. I change the permissions, I can access it - that's fine.

However, when I change the permissions so IUSR can actually access it (which it says it already has anyway), it still doesn't work and I still can't view it. When I try and change the root directory for the images (so in this case /images/ as I'm using direct now) it says "An error occured while applying security information to: [filedir] Failed to enumerate objects in the container. Access is denied" so I can't change those files.

What's confusing me is the fact that it says IUSR and ServerName\IIS_IUSRS has access to read and write yet it's giving me a 404 error. Any ideas? I'm using IIS 8 as a web server and I'm also on an OVH dedicated server.

Edit:
I should also add that it has only been doing it for the past 2-3 days. Before then, it's been fine (even on datefolders).

 

[Rodolfo]

Things is that those are server failures or misconfiguration. Sadly I can't give you more workarounds because I don't work with Windows servers.

 

[Zangoose]

Things is that those are server failures or misconfiguration. Sadly I can't give you more workarounds because I don't work with Windows servers.

I just don't really get why it was working before and suddenly it is not. Nothing had been updated or changed (perhaps the web.config - but they are at what they should be now). If it's a server failure, I should get a log file and I don't. Do you have any idea what the misconfiguration may actually be at all?

 

[Rodolfo]

Nope, but if the server is not managed by you, your hosting company can change it then that is your answer. Most likely is this:

You might notice that when you create a new directory using this code:

mkdir($dir, 0777);

The created folder actually has permissions of 0755, instead of the specified
0777. Why is this you ask? Because of umask(): http://www.php.net/umask

The default value of umask, at least on my setup, is 18. Which is 22 octal, or
0022. This means that when you use mkdir() to CHMOD the created folder to 0777,
PHP takes 0777 and substracts the current value of umask, in our case 0022, so
the result is 0755 - which is not what you wanted, probably.

The "fix" for this is simple, include this line:

$old_umask = umask(0);

Right before creating a folder with mkdir() to have the actual value you put be
used as the CHMOD. If you would like to return umask to its original value when
you're done, use this:

umask($old_umask);

I will include this workaround in 2.5.7