2 ms·

MONITOR can only be used through redis-cli or telnet, you already need a very high level of access to the server for that. I'm thinking about more subtle method

MONITOR can only be used through redis-cli or telnet, you already need a very high level of access to the server for that. I'm thinking about more subtle methods of using this info, where a client might be able to get info about the activity of other clients (or other users of the same client through something like a web application). If someone already has full access to the redis server, then yeah, I can't imagine how this would expose anything more than what's already available.

jhgg 7y ago
What? MONITOR is a command like all other commands - you can run it from a client, or really, anything that can establish a TCP a connection to the Redis server. (Eg telnet.).
- 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 ago
    Yes, 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.

jhgg 7y ago

What? MONITOR is a command like all other commands - you can run it from a client, or really, anything that can establish a TCP a connection to the Redis server. (Eg telnet.).

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 ago
  Yes, 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.