golint is complaining

21:25:56 ---> Making bundle: validate-lint (in bundles/1.13.0-dev/validate-lint)
21:25:56 Errors from golint:
21:25:56 container/container.go:293:1: exported method Container.ParseUserGrp should have comment or be unexported
21:25:56 
21:25:56 Please fix the above errors. You can test via "golint" and commit the result.
21:25:56 

Given that the major use case (perhaps only one?) is to make the files owned by the current user, would having an option to just specify current user be nicer?

perhaps but I'd like to hear from the people who asked for this to know if the use case is "current user" vs "some non-root user".

@ardnaxelarak I tested this with user namespace and it didn't seem to work properly. I had no new files after ADD instruction.

golint is complaining

fixed

@ardnaxelarak I tested this with user namespace and it didn't seem to work properly. I had no new files after ADD instruction.

I've reproduced this locally and will look into it.

ping @estesp you also mentioned a suggestion to keep permissions as-is from the host; perhaps you could join this discussion to see if there's overlap / conflicts between that option, and the one that's implemented here?

@ardnaxelarak I tested this with user namespace and it didn't seem to work properly. I had no new files after ADD instruction.

This seems to be working (for me at least) now.

EDIT: never mind, it's broken again.

thanks @thaJeztah

Yes, this came up recently in a discussion around why ADD/COPY of non-tar files always gets chowned to root:root, but if I ADD a tar, the permissions & ownership are preserved from the originating tarfile. Meaning I can almost replicate the desired behavior if I always package up my source files into a tar and then ADD the tar. But, that should not be a requirement on users (as it becomes a painful pre-docker build step every time a file is changed), and made me want to dig into what the impetus for the current behavior is (always using fixPermissions at the end of the copy step to chown to 0:0)

If no one can find a good reason [I'm not "old" enough in the codebase to have been around when that code was put there], I think a first step is to stop that blind chown on COPY/ADD operations, and then see what use cases are left where the originating permissions/ownership is not good enough. My only thought is that maybe at that point a USER-like directive near the top of the Dockerfile with a flag/mnemonic for "KEEP" or "OWNER" would be followed by any file operations via COPY and ADD through the rest of the file.

The user namespace issue should be fixed now, still trying to figure out how to write a test for it.

@ardnaxelarak there is no need in test while patch in design-review.
@duglin I'd like to know who are people who wanted this, because I thought all the time that it was you :)

@LK4D4 actually no I don't have a need for it - but there are people who have been asking for it - see: #9934 #7537 #13600 - look for the +1's on some of the comments.

I want this MR.

Currently I am doing this

FROM docker-reg/awl-tomcat:latest
ADD https://tomcat.apache.org/tomcat-7.0-doc/appdev/sample/sample.war /usr/share/awl-tomcat8/webapps/ROOT.war
USER root
RUN chown www /usr/share/awl-tomcat8/webapps/ROOT.war
USER www
VOLUME /usr/share/awl-tomcat8/webapps/

With this MR, I will be able to simply do this:

FROM docker-reg/awl-tomcat:latest
ADD --user www https://tomcat.apache.org/tomcat-7.0-doc/appdev/sample/sample.war /usr/share/awl-tomcat8/webapps/ROOT.war

The VOLUME instruction will be included directly in the image docker-reg/awl-tomcat:latest

Closing in favor of #28499

please add comments on the idea and code in there.

This is now implemented through #34263, which is included in Docker 17.09 and up