notify_push
notify_push copied to clipboard
Socket default permissions are insecure
The default permissions for the socket file are:
~/:ls -l /run/nextcloud/notify_push
srw-rw-rw- 1 nextcloud users 0 Sep 8 07:29 /run/nextcloud/notify_push=
Although that is a problem, but it can be worked around
If you create the run directory with the service file, then don't. Use systemd's tmpfiles daemon instead
In /etc/tmpfiles.d/notify_push.conf create folders with linux ACL-s
d /run/notify_push 0711 root root - -
d /run/notify_push/site1 0700 site1 site1 - -
A+ /run/notify_push/site1 - - - - u:caddy:rwx,d:u:caddy:rwx,d:m:rwx,d:g::---
d /run/notify_push/site2 0700 site2 site2 - -
A+ /run/notify_push/site2 - - - - u:caddy:rwx,d:u:caddy:rwx,d:m:rwx,d:g::---
Replace caddy with nginx or whatever your user is that serves nextcloud's stuff
site1 and site2 is the php-fpm processes' users for separate nextclouds on the same machine.
BTW, the latter users don't even have their groups (whose member is caddy or nginx's user in traditional setups): nextcloud folders and php-fpm sockets' folders have similar ACL settings...
Back to the topic. The previous conf will result in
- a parent folder for all sites' notify_push - non root users can only enter it, but can't list it's contents
- separate folders below the prev., to where only the users with the same name as the folder (as their owner) and the webserver can enter - if they know about it, see prev point.
- socket that placed in them are accessible for everyone, but effectively nobody but the respective user and the webserver
the
d:u:caddy:rwxmeans that newly created files will be rwx by caddy (disdefault)
systemd will read the conf on startup, but you can create the folders without restart with systemd-tmpfiles --create /etc/notify_push.conf
Hiding not restricted files in restricted directories is a common UNIX kinda thing. Personally I manage all my socket creating services like this: redis, php-fpm, postgresql....