Directory ownership test fails with docker

[mgsloan]

stack build in a repo that builds in a docker container results in

You are not the owner of '/home/mgsloan/.stack/'. Aborting to protect file permissions.
Retry with '--allow-different-user' to disable this precaution.

Despite me owning that folder. stack exec --allow-different-user -- whoami reports stack, and stack exec --allow-different-user -- ls -la /home/mgsloan shows a .stack folder owned by stack, so I'm not sure what's going wrong here. I haven't looked at the code yet, could be something simple.

Docker is discussed a bit in the PR - #1599 - but I didn't test it.

[mgsloan]

Pinging @sjakobi

[sjakobi]

I should have done some testing with Docker in the first place…

I just reproduced the bug on my system but don't currently have the time to look into this more closely. I'd propose that I revert my commits (2c2e15a and 260ea31) and look into this next week.

[mgsloan]

@sjakobi No worries, that's why it's a development branch! I've reverted the merge. This means that your new PR should start with reverting the revert, via git revert 0a89c9c29d744a4955e62b59774036e98d6b1e8e (as described in "reverting the revert" here).

[sjakobi]

Thanks! I've also reverted the relevant changelog edit
(260ea31).

2016-02-12 0:23 GMT+01:00 Michael Sloan [email protected]:

@sjakobi https://github.com/sjakobi No worries, that's why it's a
development branch! I've reverted the merge. This means that your new PR
should start with the commit that's created by reverting the revert, via git
revert 0a89c9c (as described in
"reverting the revert" here
https://git-scm.com/blog/2010/03/02/undoing-merges.html).

—
Reply to this email directly or view it on GitHub
#1777 (comment)
.

[borsboom]

My guess is that the ownership test is being done by the stack process in the container before it has setuid itself to the the host user (since processes in Docker containers run as root by default). The simplest solution is probably to disable the check when re-spawned in Docker (use Stack.Docker.getInContainer to check).

[mgsloan]

That makes sense. The checks for the outer stack invocation work, but not the inner. I did a little bit of print debugging yesterday, and stack thought it was user 0, whereas ~/.stack is owned by user 1000.