4 ms·
Right, but if someone has the ability to run arbitrary commands on your redis server, they can already look at or do whatever they want with your data. We're ag
by Deimorz 7y ago
Right, but if someone has the ability to run arbitrary commands on your redis server, they can already look at or do whatever they want with your data. We're agreeing: if someone can already run MONITOR, this won't make anything worse.
- jhgg 7y agoYes, and my point is, if the client is connecting to a redis server, it can just run MONITOR to see all the "sensitive" data you are talking about, and thus, this new feature poses no additional privacy risk. If you cannot trust your client to talk to your database, this isn't a problem with the database, but a problem with the client. In your specific example, your client is also probably the one issuing the commands to store and retrieve the private messages in Redis - meaning, it already has access to all the data required for a breach. If you have an unrelated workload that is accessing a shared redis, but it does not need access to the sensitive data, perhaps, use an ACL to limit clients from the alternate workload to a different redis DB (which provides some level of isolation), or simply use a different redis entirely, and don't allow clients running the alternate workload to connect to the database that contains sensitive data.