The problem/use-case that the feature addresses

Currently if you require auth via a requirepass ... conf entry, then both unix socket and TCP socket connections to Redis require you to authenticate prior to any other usage. That includes automated scripts that run on the same machine as the Redis server.

Description of the feature

Allow automated scripts that connect over unix sockets to automatically be considered to authenticated. This could be controlled by a specific option (defaulting to off) or a check on the source user of the unix socket to see if it matches the server's OS user or group via getpeerid (https://linux.die.net/man/3/getpeereid).

Alternatives you've considered

Extending AUTH / ACL to consider the source of the connection so that a CIDR or pattern could be used for more fine grained control of which types of connections require authentication. PostgreSQL's HBA (Host Based Access Control) handles this type of thing: https://www.postgresql.org/docs/current/auth-pg-hba-conf.html

I think that'd be too complicated though.

Additional information

Access to unix sockets can be controlled by file permissions so the user still has the ability to restrict automated access to a subset of the local machine.

Allowing access to the same OS user via unix sockets without a password does not open anything new up as that user can already kill the redis server, read the process's memory, and likely read the startup parameters or conf file to get the required password.

Comment From: madolson

@sehrope Would you be willing to load a module to complete your task? There is a sever event notification that exists today which you can use today and use to authenticate automatically to a user. It doesn't support introspection into the type, but I think that would be easy to add for your use case. That would be easy and super flexible for us and others.

Comment From: sehrope

I think something like this is common enough that it'd be nice to be a part of core.

For the module approach, are you saying that we'd need to add a way to see the client's connection in the module event?

Comment From: madolson

  1. Yeah, I'm not necessarily disagreeing with the point that it is probably useful. Just that we would want a more complete solution like what pg has.
  2. Basically yes

Comment From: oranagra

@yossigo WDYT?

Comment From: yossigo

@oranagra First party modules?

I think it makes sense, although if it becomes part of the core we will need to agree on where we draw the line and resists feature creep because a complete pg-hba really makes more sense as a (first party) module.

Comment From: oranagra

i agree Host Based Access control makes sense as a first party module, and if exists then maybe there's no need for this feature in the core. But on the other hand, such a feature like allowing Unix sockets to bypass auth seems much more common, and it's implementation in redis is trivial (won't add more than some 4 lines of code), maybe we want to support it anyway (just because we think it is common)

Comment From: madolson

I think the next followup to "unix socket to bypass auth" will then be "localhost connections should be able to bypass auth", and that will quickly lead to restricting various users depending on the inbound IP address. I do think this should entirely be pushed to a first party module unless we want to add a good bit of configuration to the ACL system for restricting who can login.

I can see the appeal though. I would probably want to implement it as a flag on a user. 1. If it's on the default user, you automatically are authenticated as the default user on login. 2. If it's on any other user, if you connected over a unix socket you can authenticate as that user with any password.

Comment From: clarfonthey

Just want to add onto this, I would also very much like this feature. For local installations (only listening on localhost), I would prefer a unix-socket-only version of auth where the system user is used as the username and the password is not needed; this solves the problem of deciding when a user should be allowed to access the server.

An example of another system that does this is PostgreSQL, which calls it "peer authentication": https://www.postgresql.org/docs/10/auth-methods.html#AUTH-PEER

Essentially, what I'm envisioning:

  1. ACLs have two additional options: peer and peer:name, where name is any valid POSIX username.
  2. The plain allowpeer option is a shorthand for allowpeer:name with the username for the ACL. It allows cases where the system username is different from the database user, e.g. if you want to give root access to a specific database.
  3. The default user is augmented with the rules allowpeer:root and allowpeer:redis, where redis is the user the redis instance is currently running as.
  4. With the allowpeer:name option, users accessing via the unix socket with the system user name will automatically succeed authentication, as if they had performed a valid AUTH command.

This helps solve a few different use cases:

  1. Since root can always access the default user, someone with direct server access can debug ACL issues without restarting redis.
  2. Scripts running commands directly on the server can authenticate without having access to any passwords.
  3. Single-server setups can use a single redis instance without having to create passwords for each service.

Note that the finer details for this can be modified based upon what seems right; I mostly used the "peer" term since it's already in use and can help users who are already familiar with it, and suggest modifying the ACL system since it seems like the path with the least friction for implementation.

EDIT: Rereading this, @madolson already mentioned drawing from what PG already has, but I skimmed too quickly. Either way, hopefully the summary is useful to people who aren't familiar with it.