Bug #67244 [Com]: Wrong owner:group for listening unix socket

From: Date: Fri, 30 May 2014 15:10:28 +0000
Subject: Bug #67244 [Com]: Wrong owner:group for listening unix socket
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-185988@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=67244&edit=1

 ID:                 67244
 Comment by:         carl dot george at rackspace dot com
 Reported by:        bugs-php at antipoul dot fr
 Summary:            Wrong owner:group for listening unix socket
 Status:             Open
 Type:               Bug
 Package:            FPM related
 Operating System:   Linux
 PHP Version:        5.5.12
 Block user comment: N
 Private report:     N

 New Comment:

I agree that the comment is misleading.  Please clarify this in all versions, not just 5.6.


Previous Comments:
------------------------------------------------------------------------
[2014-05-12 09:25:30] bugs-php at antipoul dot fr

In the commented file packaged by Debian, the default chmod is correct (0660).

But the other comment, regarding the owner of the unix socket is plainly wrong.

It could be modified, but I liked the idea where it just copies the settings from user/group. If the
worker from FPM is run with a particular user/group, then the socket should belong to it…

------------------------------------------------------------------------
[2014-05-11 23:12:59] peter dot mescalchin at gmail dot com

Yeah this is somewhat related to my ticket https://bugs.php.net/bug.php?id=67175 basically the
permissions for the socket have changed from 0666 to 0660 as of 5.5.12.

What I think has been happening in your case:

- The socket was always being created as root:root
- Since the socket WAS 0666 any process could hook into it (e.g. Nginx)
- Now that's no longer the case.

Also the comments around "Default Values: user and group are set as the running user" is a
little confusing - it's NOT the user that the php-fpm childs will run as (user=/group=) but the
user that starts the php-fpm daemon - which if from upstart/init.d/systemd will typically be root
(and a good choice).

In your final example it's working as expected - the default group for the www-data user is
www-data so it's using that. There is zero interaction between (user=/group=) and
(listen.owner=/listen.group=) settings.

In the end this all boils down to improvements in both PHP documentation and comments in
php-fpm.conf. I have submitted a change to the PHP docs (to say that default is 0660 - not committed
yet) - php-fpm.conf has some changes coming for PHP 5.6, but maybe this confusion you have here
could be better explained.

------------------------------------------------------------------------
[2014-05-11 07:49:29] bugs-php at antipoul dot fr

Description:
------------
After upgrading to 5.5.12 that fixes #67060, my FPM instances (I have two of them) since to be
unreachable from my nginx web server.
I am using unix socket to communicate between nginx and fpm.
The sockets belong to root:root, which is NOT what is configured:

  user = www-data
  group = www-data

This are the settings for the running process, but later in the file, it says the following:
  
  ; Set permissions for unix socket, if one is used. In Linux, read/write
  ; permissions must be set in order to allow connections from a web server. Many
  ; BSD-derived systems allow connections regardless of permissions.
  ; Default Values: user and group are set as the running user

Unfortunately, sockets are created with root:root ownership.

The workaround is to modify the listen.owner or the listen.group directive.

Moreover, if I have the following configuration:
  user = www-data
  group = nas
  listen.owner = www-data

Then the socket is created with www-data:www-data ownership. This should be www-data:nas


See the www.conf
(https://cloud.antipoul.fr/public.php?service=files&t=d9c210c044dbf507d65aafb9af317090&download)
and cloud.conf
(https://cloud.antipoul.fr/public.php?service=files&t=c14885c0cd990c28ed42672f91b97c3a&download).



------------------------------------------------------------------------



--
Edit this bug report at https://bugs.php.net/bug.php?id=67244&edit=1


Thread (7 messages)

« previous php.bugs (#185988) next »