Skip to content
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

Disallow running as root unless really stubborn #400

Open
wants to merge 1 commit into
base: 1.8
Choose a base branch
from

Conversation

NicolasT
Copy link
Contributor

@NicolasT NicolasT commented May 2, 2014

No description provided.

@domsj
Copy link
Contributor

domsj commented May 27, 2014

Sorry for leaving this hanging for such a long time ... I'm still a bit unsure about this one.
I'm totally pro not running arakoon as root, but the same could be said about not running with fsync=true (which is an even worse thing to do imo).
So I think that we want to handle both cases in the same way ... wether that's the warning in the log or refusing to start -- unless a certain env variable or tainted config setting is present.
Btw is there a reason here to prefer an env variable over a tainted config setting?

@NicolasT
Copy link
Contributor Author

I wouldn't implement this using some warning in a log: nobody will ever see that anyway.
I used an environment variable instead of a configuration setting because

  • Unlike the fsync thing, this isn't related to how an Arakoon node operates at runtime. It's meant to prevent any runtime at all.
  • I figure some would without any hesitation add __tainted_run_as_root = true to their Arakoon configuration file template. Managing environment variables might be slightly harder depending on the deployment system in use.
  • When using the work-around, it's more clear at the location of the exec call one is doing something fishy.

@domsj
Copy link
Contributor

domsj commented May 27, 2014

By the same token nobody is going to see the fsync warning in the log

@NicolasT
Copy link
Contributor Author

I won't disagree there 😉

@domsj
Copy link
Contributor

domsj commented May 27, 2014

So do you think we should be less lenient in the fsync case?
I know it's not exactly the same thing but I'm interested in your opinion.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants