Implement dropping user/group privileges for redis-server. #554

Closed
wants to merge 1 commit into
from

Projects

None yet

9 participants

@christianparpart

It is not a good advice to just invoke sudo or su to run redis-server
in non-root, nor is it good to run it just as root.
However, there are environments/circumstances, where
start-stop-daemon/startproc are not meant to be used,
e.g. when writing platform independant resource agents,
or, when you have to keep the dependencies as low as possible.

This patch adds a new configuration variable "user" that gets one
string argument, and the redis-server tries to drop its
group and user privileges down to this user and this user's groups
and exits early on failure.

I would also like to get this commit cherry-picked to 2.x branches,
especially 2.2, since this is, what Ubuntu 12.04 is shipping with.

@christianparpart christianparpart Implement dropping user/group privileges for redis-server.
It is not a good advice to just invoke sudo or su to run redis-server
in non-root, nor is it good to run it just as root.
However, there are environments/circumstances, where
start-stop-daemon/startproc are not meant to be used,
e.g. when writing platform independant resource agents,
or, when you have to keep the dependencies as low as possible.

This patch adds a new configuration variable "user" that gets one
string argument, and the redis-server tries to drop its
group and user privileges down to this user and this user's groups
and exits early on failure.

I would also like to get this commit cherry-picked to 2.x branches,
especially 2.2, since this is, what Ubuntu 12.04 is shipping with.
05d7fb9
@paulasmuth

+1 - would love to see this in 2.4/2.6 :)

@pietern
Contributor
pietern commented Jun 16, 2012

Who gives advice to run Redis as root?

I don't see why anyone would do that, beyond running Redis on a sub-1024 port. I believe this is the responsibility of the process starting Redis, not of Redis itself.

Closing the issue. It can be reopened when there are compelling reasons to do so.

@pietern pietern closed this Jun 16, 2012
@christianparpart

Hey pietern. it is not about running as root, it is about how to drop root. This patch was inspired by searching for a RA (resource agent) for Pacemaker (high availability solution), and I found a two, and they did not yet get pulled into the set of resource agents because they were using 3rd-party tools like sudo/start-stop-daemon, just to drop root.
The reason was: those tools are not on every UNIX flavor, nor act they the same. So it is just good to be capable of dropping root yourself.

@fredx
fredx commented Sep 27, 2012

@pietern - who gives advice to run as root? No one, I hope. The docs for Redis do call this out. But the install_server script DOES THIS BY DEFAULT.

As an admin, you have to take several extra steps to make Redis not run as root. And I don't see any suggestions on best practices on how to change the default config script for the better.

Many other daemonized services offer the ability to set the running user via the config file instead of the init script/hack. I think you should re-open this ticket. It's a useful feature. Either that, or update your install script to run Redis correctly.

@MichaelBrenden

NOT having this option is SILLY

@Couto
Couto commented Jul 11, 2014

Any conclusion about this?
Or at least some version of the install_server script that does not run redis as root?

@christianparpart

I hardly doubt the author will merge this stuff or at least take the idea. The author didn't even lost a word of honoring the contribution, straight rejecting it with a ridiculous understatement, not trying to understand the needs for why one might even need it, nor asking for it, if he doesn't understand. Just thinking it's about non-privileged ports is actually quite short-sighted as well.

@Couto so my advice is, patch it yourself, if you do not want to (or can) depend on non-standard 3rdparty tools for privilege dropping.

Cheers

@badboy
Contributor
badboy commented Jul 11, 2014

People, please calm down.
There's certainly something that can be done. I'll take a look at the install script ASAP. The patch is so small, maybe @antirez can take a look at it and state his opinion (in the end it's up to him to merge it here).

@mattsta
Contributor
mattsta commented Jul 11, 2014

A few notes:

About the patch: it's not required, but it's a nice try. The standard answer for running a process as another user is to just... run the process as another user.

Better solution than the patch: the install script should ask you which user you want to run Redis as, then it should chown all files to that user then set up sudo -u in the init script to run Redis as that user.

As for the reason things are the way they are now:

  • The install script is considered a "free helper" script and comes with no guarantees. It's great for understanding what's required for Redis to run if you want to extend or build your own install procedures.
  • The install script creates data dirs and config files and log files all owned by root.
  • The install script places an init script in init.d which, if you enable it on startup as-is, will run Redis as root.
    • Startup files and install procedures provided by non-distro packages are always susceptible to defaults of the individual utilities and may not integrate well into your systems. It's the responsibility of the individual system owners (or distribution-level packagers) to ensure all services are running appropriately.
  • It doesn't make sense to include privilege dropping in Redis since Redis doesn't need to run on any root-privileged port. If, by mistake of configuration, Redis is running as root, then the configuration should be changed, not Redis itself. If, by mistake of configuration, all the data files for Redis are owned as root, then the files should be changed and Redis should be run as the new owner.
@badboy
Contributor
badboy commented Jul 11, 2014

Thanks @mattsta. As I said I'll try to rewrite the install helper containing your summarized points.

@antirez
Owner
antirez commented Jul 11, 2014

+1 to Matt. IMHO the short reply here is, privilege dropping is historically a mean to:

  1. Acquire some root-only resource.
  2. Drop privileges.
  3. Continue to run unprivileged.

Since Redis does not need "1" is hard to justify such a feature, if our init script is broken, let's fix that. Moreover note that it is unlikely that Redis runs in true multi-user Unix systems where to bind a privileged port is an issue, so the default port is not privileged and the way to go is to run the server on an high port.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment