Bug #67244 [Com]: Wrong owner:group for listening unix socket
Edit report at https://bugs.php.net/bug.php?id=67244&edit=1
ID: 67244
Comment by: bernard+php at rosset dot net
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:
The misleading comment is still there, more than 5 years later. Reviewing old configurations I
thought those listen.owner & listen.group directives were extraneous... which they were not.
Any hope to have those directives' comment fixed anytime soon?
Previous Comments:
------------------------------------------------------------------------
[2014-05-30 15:10:28] carl dot george at rackspace dot com
I agree that the comment is misleading. Please clarify this in all versions, not just 5.6.
------------------------------------------------------------------------
[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)