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

Error out when stack is run as root/sudo #471

Closed
radix opened this Issue Jul 1, 2015 · 18 comments

Comments

Projects
None yet
10 participants
@radix
Contributor

radix commented Jul 1, 2015

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

This comment has been minimized.

Contributor

snoyberg commented Jul 1, 2015

Thanks @radix.

@manny-fp Perhaps you have thoughts on this?

@drwebb

This comment has been minimized.

Contributor

drwebb commented Jul 1, 2015

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

@borsboom

This comment has been minimized.

Contributor

borsboom commented Jul 1, 2015

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.

@snoyberg snoyberg added this to the 0.2.0.0 milestone Jul 2, 2015

@snoyberg snoyberg modified the milestones: 0.3.0.0, 0.2.0.0 Jul 2, 2015

@alexanderkjeldaas

This comment has been minimized.

Contributor

alexanderkjeldaas commented Aug 16, 2015

-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

This comment has been minimized.

mbj commented Aug 16, 2015

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

This comment has been minimized.

Contributor

borsboom commented Aug 16, 2015

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

This comment has been minimized.

Contributor

sjakobi commented Nov 17, 2015

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
@borsboom

This comment has been minimized.

Contributor

borsboom commented Nov 20, 2015

The condition we'd really looking for is when Stack is running as root, but the ~/.stack or <project>/.stack-work directory isn't owned by root. sudo doesn't change $HOME by default, so this would detect the most common case and prevent permissions problems. But if you're running in a true root shell (with $HOME pointing to the root user's actual home directory) and building projects owned by root, Stack would continue as usual.

@sjakobi sjakobi self-assigned this Jan 4, 2016

@sjakobi sjakobi added the in-progress label Jan 4, 2016

sjakobi added a commit to sjakobi/stack that referenced this issue Jan 4, 2016

sjakobi added a commit to sjakobi/stack that referenced this issue Jan 10, 2016

Add 'allow-different-user' flag and configuration option commercialha…
…skell#471

Users other than the owner of the ~/.stack directory are now prevented
from using a stack installation in order to avoid problems with file
permissions. To disable this precaution users can pass the
--allow-different-user flag or use the 'allow-different-user'
configuration option in their ~/.stack/config.yaml.

On Windows, the new flag and configuration options have no effect.
@sjakobi

This comment has been minimized.

Contributor

sjakobi commented Feb 1, 2016

Looks like I should really get this done. :)

#1725

sjakobi added a commit to sjakobi/stack that referenced this issue Feb 3, 2016

Add 'allow-different-user' flag and configuration option commercialha…
…skell#471

Users other than the owner of the ~/.stack directory are now prevented
from using a stack installation in order to avoid problems with file
permissions. To disable this precaution users can pass the
--allow-different-user flag or use the 'allow-different-user'
configuration option in their ~/.stack/config.yaml.

On Windows, the new flag and configuration options have no effect.

mgsloan added a commit that referenced this issue Feb 4, 2016

Merge pull request #1599 from sjakobi/471-check-for-sudo
Add 'allow-different-user' flag and configuration option #471

sjakobi added a commit that referenced this issue Feb 9, 2016

@sjakobi

This comment has been minimized.

Contributor

sjakobi commented Feb 9, 2016

Fixed with #1599.

@sjakobi sjakobi closed this Feb 9, 2016

sjakobi added a commit that referenced this issue Feb 11, 2016

sjakobi added a commit to sjakobi/stack that referenced this issue Feb 17, 2016

Add 'allow-different-user' flag and configuration option commercialha…
…skell#471, fix commercialhaskell#1777

Users other than the owner of the ~/.stack directory are now prevented
from using a stack installation in order to avoid problems with file
permissions. To disable this precaution users can pass the
--allow-different-user flag or use the 'allow-different-user'
configuration option in their ~/.stack/config.yaml.

On Windows, the new flag and configuration options have no effect.

When stack is re-spawned in Docker, the ownership check is skipped
(see commercialhaskell#1777).

This reverts commits 0a89c9c and
218e7dd.

mgsloan added a commit that referenced this issue Feb 18, 2016

Merge pull request #1801 from sjakobi/471-once-again
Add 'allow-different-user' flag and configuration option #471, fix #1777
@agocorona

This comment has been minimized.

agocorona commented Jun 12, 2017

To summarize, for a non expert both in stack and docker, what I have to do run a program in a docker image that uses a script hardcoded that uses stack and does not include the --allow-different-user? flag?

@mgsloan

This comment has been minimized.

Collaborator

mgsloan commented Jun 12, 2017

@agocorona You can set allow-different-user: true in your project config or global config.

Running stack should work in the docker container without changing user, though, hmm.

@agocorona

This comment has been minimized.

agocorona commented Jun 12, 2017

The problem is that the project config is also created automatically

I found another workaround: creating an user in the docker instance and running everithing under this user:

RUN useradd -ms /bin/bash  newuser && su newuser
@alexanderkjeldaas

This comment has been minimized.

Contributor

alexanderkjeldaas commented Jun 12, 2017

Maybe I'm wrong about this, but I think stack still can't bootstrap ghcjs when running as root. The requirement to add allow-different-user: true infects the ghc-build so ghcjs (and maybe ghc) needs to be patched as well.

What's the expected behavior for bootstrapping compilers when running as root?

@alexanderkjeldaas

This comment has been minimized.

Contributor

alexanderkjeldaas commented Jun 12, 2017

@agocorona creating a user in the docker image creates endless pain when you want to mount your build environment into the docker container.
(the reason being that uids in docker containers depend on the order in which users are added and thus does not compose in any meaningful way)

that's definitively an anti-pattern, and a reason why stack absolutely should work flawlessly as root and another reason why the basis for this issue is wrong.

I'm doing that currently with stack, because it's the only way to get it to work with ghcjs, but it's awful, and there's nothing but this feature request that is creating all of this pain.

@agocorona

This comment has been minimized.

agocorona commented Jun 14, 2017

@alexanderkjeldaas .Yes I experienced these problems. I agree with you. stack shouldn't care about permissions more than the user of stack itself and the Operating System. It should not dictate what are good or bad practices, specially since the usage cases evolve fast. My experience is that --allow-different-user do not work in medium to large compilations for unknown reasons. For this reason I use cabal under docker, but in this case, stack is imposed.

@ygale

This comment has been minimized.

ygale commented Aug 7, 2017

Here's another class of common use cases where this is a problem: building a project located on a file system that does not fully support the native permissions system of the shell you are running in. More specifically, you will run into this when your project is in NTFS and you try to build with stack from a unix-like environment. There are many combinations:

  • WSL, Msys2, or Cygwin on Windows
  • An NTFS partition on MacOS, Linux, *BSD, etc.

In these kinds of cases, all of the files you create show as being owned by root, even though you are not root. So stack refuses to run, claiming that you are not the owner, even though actually you yourself created the files normally without sudo.

@agocorona

This comment has been minimized.

agocorona commented Oct 10, 2017

adding:

   allow-different-user: true

in config.yaml in the /.stack/config.yaml

solved all my problems.

It seems to be more general than adding it to the command line

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