FS_CHMOD_DIR not functioning correctly with setgid
|Reported by:||jrmuir||Owned by:|
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.