FS_CHMOD_DIR not functioning correctly with setgid

[jrmuir]

This happens with no plugins enabled and default twentyten theme. It occurs on RHEL6 running PHP5.3.6, any browser as it's server-side.

The directories where the files/folders are being created already have setgid toggled, but wordpress is now overriding that setting when creating new directories.

If I provide setgid in the FS_CHMOD_DIR value, it is incorrectly set when running automatic functions such as installing a new plugin.
For example, if "define('FS_CHMOD_DIR', (2770 & ~ umask()));" is set in wp-config.php and I attempt to install a new plugin, the permissions in the upgrade folder are set to 5320 and the installation fails as it can't read the files from that directory. If set to 1770, the resulting directory permissions are 3350. This isn't expected behavior to me.

With the FS_CHMOD_DIR value of 2770 should, unless I'm completely mistaken about what the functionality was meant to provide, it should set the exact permissions the same as a chmod call would, of 2770. As noted above, it's being set to 5320. The permission of the folder in octal value can be verified by 'stat newplugindirectory --format %a'. For me, when set to 2770 (or drwxrws---) the plugin installer actually fails as it creates files it can't read (value 5320 or d-wxr-s--T).

I may be able to get by with 0770 but I have sftp users connecting/uploading that have different user/group id's than what the sites run as and use setgid on directories to ensure that newly created directories/files are created with the correct group and that access is granted to those sftp users. It's a common unix "shared" or "common" directory type configuration (see ​http://my.safaribooksonline.com/book/operating-systems-and-server-administration/linux/0596006403/managing-files-and-partitions/linuxckbk-chp-9-sect-7 for an example)

I first noticed this behavior in 3.1.2, but it also affects 3.2.1 in my testing. It was not a problem in 3.0.x.

[dd32]

With the FS_CHMOD_DIR value of 2770 should, unless I'm completely mistaken about what the functionality was meant to provide, it should set the exact permissions the same as a chmod call would, of 2770

You're not mistaken with the use of the constant, however you are defining it wrong.

Chmod values are specified in an Octal format, in PHP to define an octal number, you need to prefix it with 0, Eg:

var_dump( array( 2770, 02770 ) );
// output converts to Base10:

array
  0 => int 2770
  1 => int 1528

As you can see, prefixed with 2 it comes out as the Base10 version, which is going to cause problems in chmod values, in octal it comes to (decimal)1528.

Can you just check to see if i'm on the right track there?

[jrmuir]

That makes sense, I wasn't aware of the 0 to start an octal requirement. Tested, and you are correct. I'll see if I can make an update (or comment at least) on the documentation talking about permissions to reflect that requirement.