-
Notifications
You must be signed in to change notification settings - Fork 1.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
enable redis connection via unix domain socket instead of tcp #204
Comments
You can make some edits to your
Then, within your Node app, you can do the following to connect to your Redis server: var redis = require('redis');
var redisClient = redis.createClient('/tmp/redis.sock'); |
ah, great. thank you. |
Can this be documented in README also? So it can be easier and obvious to find. |
@chakrit If you want to write up a small pull request for the README I'll accept it :) |
@brycebaril @mranney There you go ^ Hope 2 months' not too late :p |
I could not get it to work without setting the socket to 777, which is a shame, but 755 makes it impossible to disconnect. Before with
After, with
I suppose the more secure way to do this would be to add redis server and your application user to the same group and make the group owner of the socket mirror that group, and then set the socket to 775. |
@apotek there is not much that node_redis itself is able to do about the socket permissions. This depends on how you set everything up. |
@BridgeAR I agree node_redis can't do anything about how socket permissions are set up. Of course that is the case. However, 1) A node application shouldn't have to run as root. Do we agree? 2) If we agree on 1, and a node application is not running as root, under the default socket permissions 755, node_redis cannot use the socket. 3) Changing the socket permissions to 777 fixes this, but is not secure. My conclusion is that without node_redis being able to work with a socket set to 755 while sharing that resource with the user the node app is running as, it is impossible to use node_redis over a socket securely. The most secure fix possible at the moment is to set the socket to 775, and add the user that the node application is running as to the redis group. Or, run the node app as the redis user (which could cause other problems). The issue is that the socket needs both the redis user and the node app user to write to it. Most sockets don't do this. One user writes, and other users read. See mysql socket for example. You can connect to it as a 755 socket regardless of who you are, because you don't have to write to it. So my point is to see if node_redis could be refactored to not force the node app that is using it to write to the socket. |
If this was on Stackoverflow I would upvote it. |
@kwidholm-tm as far as I see it, the reason why you need higher permissions is the directory of your socket file. This has nothing to do with node_redis. It is perfectly fine to run a socket without root rights, if you place the file somewhere else than in I might implement a check to test the privileges on the socket file to improve the error message though. |
What about using setfacl for setting permissions on linux ? We can add the user running a redis client to a list somewhere. This is done by php-fpm for instance. We tend to run different types node workers under different groups. So we could just authorize specific group to write into redis |
Also, once connected to Redis via socket, check if everything is running accordingly.
|
this help me to understand
but it would be way more secure with 770 instead of 775which works well for me thank to @kwidholm-tm |
If redis is started using systemd just override the group.
[Service]
Group=_rspamd Just that. This will create a systemd unit override without changing global unit files. Specify the group name under which the socket should be created. Make a file public read/writable is almost always a very bad idea. |
atm, there seems no possibility to use unix domain socket instead of tcp socket to connect to redis.
due to speed issues, that'd be a great benefit
The text was updated successfully, but these errors were encountered: