aspnet / aspnet-docker

[Archived] ASP.NET Core Docker images for 1.x. Go to https://github.com/dotnet/dotnet-docker for 2.1 and up.
https://asp.net
719 stars 171 forks source link

Running aspnetcore-build as non-root with --user fails #271

Closed heebj closed 7 years ago

heebj commented 7 years ago

I want to use the aspnetcore-build image to compile my code on our continuous integration server. However the build user is not root and I need to start the docker container with the --user parameter so that the build output has the correct owner in the mounted src directory:

docker run -v $(pwd):/src --workdir /src/backend microsoft/aspnetcore-build:latest bash -c "dotnet restore && dotnet build"

When I start the build task I get the following error:

/usr/share/dotnet/sdk/1.0.4/NuGet.targets(97,5): error : Failed to read NuGet.Config due to unauthorized access. Path: '/.nuget/NuGet/NuGet.Confi
/usr/share/dotnet/sdk/1.0.4/NuGet.targets(97,5): error :   Access to the path '/.nuget/NuGet' is denied. [/src/backend/Exchange.Backend.sln]
/usr/share/dotnet/sdk/1.0.4/NuGet.targets(97,5): error :   Permission denied [/src/backend/Exchange.Backend.sln]

It seems that most files of the .NET Core SDK in the image are owned by root and only readable by root and therefore a non root user cannot build mounted code.

Is this intended? Shouldn't the permissions by changed to be at least readable?

natemcmaster commented 7 years ago

This looks like a duplicate of https://github.com/NuGet/Home/issues/5106 and https://github.com/dotnet/dotnet-docker/issues/229

heebj commented 7 years ago

Not only nuget seems to be the problem. Also when running code inside a dotnet container it tries to access a files in the not existing home directory of the running user:

System.UnauthorizedAccessException: Access to the path '/home/exchangePublic/.dotnet/corefx/cryptography/crls' is denied. ---> System.IO.IOException: Permission denied

natemcmaster commented 7 years ago

It seems like the customer user you are attempting to use isn't configured correctly. How did you create the user in the container?

heebj commented 7 years ago

I did not create the running user within the container but on the host system and pass it via the --user parameter when calling docker run.

natemcmaster commented 7 years ago

@heebj you should define the user in the docker container before you run it. The base image uses the default docker user (root). Assuming you're using the default Linux image (debian), you need to call useradd and groupadd to define the user, home folder, group, etc. For example: https://gist.github.com/alkrauss48/2dd9f9d84ed6ebff9240ccfa49a80662

heebj commented 7 years ago

@natemcmaster That's what we finally did to get it running, thanks.

But what about the aspnetcore-build image? I think the image should be useable in a CI environment as non root without having to derive a specific Dockerfile. I once also got an error that dotnet.dll cannot be accessed when building code in the mounted directory. dotnet.dll is only readable for root...

natemcmaster commented 7 years ago

I think the image should be useable in a CI environment as non root without having to derive a specific Dockerfile.

This is not something we plan to change. Our images use the default user as specified in the lowest-level images. i.e. try this: docker run --rm debian:jessie whoami

once also got an error that dotnet.dll cannot be accessed when building code in the mounted directory. dotnet.dll is only readable for root...

It should be readable by owner, user, and group, but if you can get a minimal repro let me know. Here is what I see in microsoft/aspnetcore-build:1.1.2

$ ls -al /usr/share/dotnet/dotnet
-rwxr-xr-x 1 1002 sudo 139184 Jun 16  2016 /usr/share/dotnet/dotnet
$ ls -al /usr/share/dotnet/sdk/1.0.4/dotnet.dll
-rw-r--r-- 1 1002 sudo 339968 May  4 22:30 /usr/share/dotnet/sdk/1.0.4/dotnet.dll
heebj commented 7 years ago

I solved it now such that I run the build task as root in the container and afterwards chown the files in the container back to the UID of the host's CI user. This way it works.