[wp-trac] [WordPress Trac] #18313: FS_CHMOD_DIR not functioning correctly with setgid

[WordPress Trac]

#18313: FS_CHMOD_DIR not functioning correctly with setgid
--------------------------+-----------------------------
 Reporter:  jrmuir        |      Owner:
     Type:  defect (bug)  |     Status:  new
 Priority:  normal        |  Milestone:  Awaiting Review
Component:  Filesystem    |    Version:  3.1.2
 Severity:  major         |   Keywords:
--------------------------+-----------------------------
 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.

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/18313>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software