Error out when stack is run as root/sudo

[radix]

It's probably wrong to run stack as root, at least in almost all cases. This came up in another thread: #464 (comment)

• Are there any use cases for running stack as root? (maybe in the docker stuff?)
• If there are, but there are very few cases, perhaps stack should error out if it's run as root, but proceed if an explicit envvar or parameter is passed? (STACK_ROOT=true or whatever)
• if there are, and they are somewhat common, perhaps stack should simply print a warning when run as root, but proceed?

[snoyberg]

Thanks @radix.

@manny-fp Perhaps you have thoughts on this?

[drwebb]

Yeah big +1, I'm up for an error and exit unless --as-root is given as an option.

[borsboom]

There are two Docker-related cases that come to mind where you might want to run stack as root:

1. Your system isn't setup to let non-root uses connect to the Docker daemon. Using sudo stack is not recommended as a solution to this problem anyway, since it will mess up the permissions of any files it writes on your host filesystem. Instead, best course of action is to allow non-root connections or use a wrapper script that automatically sudos any docker commands.

2. Occasionally you might want to poke around in a container as the root user, in which case sudo stack docker exec bash can be handy. But that should be rare so needing an override argument would be just fine.

So +1 from me.

[alexanderkjeldaas]

-1. I don't see why this behavior is wanted. Running as root is common nowadays, both in docker and with various virtual machines to simplify deployment. When I fork out $5 to buy a VM for some testing, root is what I get, and there is no reason to add a non-root user to such a machine.

I would not want this behavior. I suggest stack only print a warning, if anything at all. I'd like to understand what problem this is solving that is worth making the semantics of stack depend on EUID?

[mbj]

both in docker and with various virtual machines to simplify deployment.

Creating a non privileged user is IMO part of a "simple" deployment. There is no need to break the least amount of (EDIT:) permissions rule to attribute deployments with "simple".

[borsboom]

It is pretty common to run Docker stuff as root when using "trusted" containers, and I think it'll cause enough users grief if we prevent it that this shouldn't be an error. But running as root is different than running under sudo (without -i), which I think is at least something we should warn about and perhaps prevent (but make overridable).

[sjakobi]

How can you differentiate between running as root and running under sudo?

In both cases I get

Prelude> import System.Posix.User 
Prelude System.Posix.User> getEffectiveUserID 
0
Prelude System.Posix.User> getLoginName 
*** Exception: getLoginName: does not exist (No such file or directory)
Prelude System.Posix.User> getRealUserID 
0