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

Dockerfile: ADD does not honor USER: files always owned by root #6119

Closed
discordianfish opened this Issue May 30, 2014 · 89 comments

Comments

Projects
None yet
@discordianfish
Contributor

discordianfish commented May 30, 2014

Hi,

consider this Dockerfile:

FROM ubuntu
RUN adduser foo
USER foo
ADD . /foo

/foo in the container will be owned by root, not by 'foo' as one might expect. There are easy workaround but it's still a inconsistency which should be fixed at some point.

@LK4D4

This comment has been minimized.

Show comment
Hide comment
@LK4D4

LK4D4 May 30, 2014

Contributor

Cool, I'll do it on weekend :)

Contributor

LK4D4 commented May 30, 2014

Cool, I'll do it on weekend :)

@crosbymichael

This comment has been minimized.

Show comment
Hide comment
@crosbymichael

crosbymichael May 30, 2014

Contributor

FYI, I'm not sure we want this behavior, we will need to discuss first

Contributor

crosbymichael commented May 30, 2014

FYI, I'm not sure we want this behavior, we will need to discuss first

@abevoelker

This comment has been minimized.

Show comment
Hide comment
@abevoelker

abevoelker May 30, 2014

I'm relatively new to Docker and this had confused me at first as well. Every time I have to add files that should belong to a non-root user, I have to do RUN chown after the ADD (keeping it all above the USER line since chown needs root permission).

I had just assumed it was expected behavior and there was a good reason for it. The documentation for ADD does make it sound like expected behavior:

All new files and directories are created with mode 0755, uid and gid 0.

abevoelker commented May 30, 2014

I'm relatively new to Docker and this had confused me at first as well. Every time I have to add files that should belong to a non-root user, I have to do RUN chown after the ADD (keeping it all above the USER line since chown needs root permission).

I had just assumed it was expected behavior and there was a good reason for it. The documentation for ADD does make it sound like expected behavior:

All new files and directories are created with mode 0755, uid and gid 0.

@LK4D4

This comment has been minimized.

Show comment
Hide comment
@LK4D4

LK4D4 May 30, 2014

Contributor

Also it was in original issue about chowning, that have been done by @creack. But I was too lazy to do it and @creack also didn't do it by some reasons.
#2684 - original issue

Contributor

LK4D4 commented May 30, 2014

Also it was in original issue about chowning, that have been done by @creack. But I was too lazy to do it and @creack also didn't do it by some reasons.
#2684 - original issue

@unclejack

This comment has been minimized.

Show comment
Hide comment
@unclejack

unclejack May 30, 2014

Contributor

I don't think making ADD set file ownership to whatever user the USER instruction has set above is a good idea. USER was initally added to specify the user which the commands executed by RUN or CMD should be run under.

Contributor

unclejack commented May 30, 2014

I don't think making ADD set file ownership to whatever user the USER instruction has set above is a good idea. USER was initally added to specify the user which the commands executed by RUN or CMD should be run under.

@discordianfish

This comment has been minimized.

Show comment
Hide comment
@discordianfish

discordianfish Jun 1, 2014

Contributor

@unclejack Why do you think this isn't a good idea? I think it's what the user expects: All following operations will be executed as the given user.

Contributor

discordianfish commented Jun 1, 2014

@unclejack Why do you think this isn't a good idea? I think it's what the user expects: All following operations will be executed as the given user.

@divoxx

This comment has been minimized.

Show comment
Hide comment
@divoxx

divoxx Jun 3, 2014

I just got bitten by this and gotta say it's a surprise that ADD does not respect the preceding USER declaration. If someone wants to add as root, simply run ADD before the USER is set to something else, as one would do w/ RUN.

+1 for this

divoxx commented Jun 3, 2014

I just got bitten by this and gotta say it's a surprise that ADD does not respect the preceding USER declaration. If someone wants to add as root, simply run ADD before the USER is set to something else, as one would do w/ RUN.

+1 for this

@discordianfish

This comment has been minimized.

Show comment
Hide comment
@discordianfish

discordianfish Jun 20, 2014

Contributor

Keep in mind we're recommend that people run their services as a non-privileged user. Inconveniences like this behavior will prevent people from following that.

Contributor

discordianfish commented Jun 20, 2014

Keep in mind we're recommend that people run their services as a non-privileged user. Inconveniences like this behavior will prevent people from following that.

@crosbymichael

This comment has been minimized.

Show comment
Hide comment
@crosbymichael

crosbymichael Jun 20, 2014

Contributor

Are there any issues running a chown after you add things?

Ref: https://github.com/crosbymichael/influxdb-docker/blob/master/Dockerfile#L9

Contributor

crosbymichael commented Jun 20, 2014

Are there any issues running a chown after you add things?

Ref: https://github.com/crosbymichael/influxdb-docker/blob/master/Dockerfile#L9

@tianon

This comment has been minimized.

Show comment
Hide comment
@tianon

tianon Jun 20, 2014

Member

Doesn't AUFS have issues with tracking ownership/mode changes?

Member

tianon commented Jun 20, 2014

Doesn't AUFS have issues with tracking ownership/mode changes?

@crosbymichael

This comment has been minimized.

Show comment
Hide comment
@crosbymichael
Contributor

crosbymichael commented Jun 20, 2014

@tianon yes

@LK4D4

This comment has been minimized.

Show comment
Hide comment
@LK4D4

LK4D4 Jun 20, 2014

Contributor

@crosbymichael yeah, this is very inconvenient. for example I have postgres image, there is already USER postgres in it, so I need to do:

USER root
RUN chown
USER postgres

Also I must know about USER postgres in base image.

Contributor

LK4D4 commented Jun 20, 2014

@crosbymichael yeah, this is very inconvenient. for example I have postgres image, there is already USER postgres in it, so I need to do:

USER root
RUN chown
USER postgres

Also I must know about USER postgres in base image.

@pikeas

This comment has been minimized.

Show comment
Hide comment
@pikeas

pikeas Aug 11, 2014

Proposal: a second form of the ADD command. I'd love to be able to do:

ADD ["filename", "owner", "group", "755"]

pikeas commented Aug 11, 2014

Proposal: a second form of the ADD command. I'd love to be able to do:

ADD ["filename", "owner", "group", "755"]
@cyphar

This comment has been minimized.

Show comment
Hide comment
@cyphar

cyphar Aug 20, 2014

Contributor

I open a proposal a few days ago that addresses this issue: #7537. Essentially, after talking on IRC, it was decided that only COPY should have this particular behaviour (and ADD will be backward compatible until it is deprecated and removed).

Contributor

cyphar commented Aug 20, 2014

I open a proposal a few days ago that addresses this issue: #7537. Essentially, after talking on IRC, it was decided that only COPY should have this particular behaviour (and ADD will be backward compatible until it is deprecated and removed).

@ericchaves

This comment has been minimized.

Show comment
Hide comment
@ericchaves

ericchaves Jan 5, 2015

Hi guys, any update on this issue?

ericchaves commented Jan 5, 2015

Hi guys, any update on this issue?

@david-mccullars

This comment has been minimized.

Show comment
Hide comment
@david-mccullars

david-mccullars Jan 20, 2015

Being forced to ADD and then RUN chown has a very nasty side-effect of artificially bloating docker images. For example:

FROM busybox:latest

RUN adduser -D bob
ADD 30MB_file /30MB_file
RUN chown bob /30MB_file

I ran build on this once without the chown and once with:

➔ docker images | grep bob
test    with_chown          a27913861eca        6 days ago          65.35 MB
test    without_chown       7ab2bbe29b50        6 days ago          33.89 MB

And we can see what is happening via docker history:

 ➔ docker history test:with_chown
IMAGE         CREATED        CREATED BY                                      SIZE
a27913861eca  6 days ago     /bin/sh -c chown bob /30MB_file                 31.46 MB
7ab2bbe29b50  6 days ago     /bin/sh -c #(nop) ADD file:9474e987e88bd93248   31.46 MB
e9413ccecaa1  6 days ago     /bin/sh -c adduser -D bob                       3.955 kB
4986bf8c1536  2 weeks ago    /bin/sh -c #(nop) CMD [/bin/sh]                 0 B
ea13149945cb  2 weeks ago    /bin/sh -c #(nop) ADD file:8cf517d90fe79547c4   2.433 MB
df7546f9f060  3 months ago   /bin/sh -c #(nop) MAINTAINER Jérôme Petazzo     0 B
511136ea3c5a  19 months ago                                                  0 B

When we consider that a large application might have several hundred megabytes or more, this chown becomes very expensive.

david-mccullars commented Jan 20, 2015

Being forced to ADD and then RUN chown has a very nasty side-effect of artificially bloating docker images. For example:

FROM busybox:latest

RUN adduser -D bob
ADD 30MB_file /30MB_file
RUN chown bob /30MB_file

I ran build on this once without the chown and once with:

➔ docker images | grep bob
test    with_chown          a27913861eca        6 days ago          65.35 MB
test    without_chown       7ab2bbe29b50        6 days ago          33.89 MB

And we can see what is happening via docker history:

 ➔ docker history test:with_chown
IMAGE         CREATED        CREATED BY                                      SIZE
a27913861eca  6 days ago     /bin/sh -c chown bob /30MB_file                 31.46 MB
7ab2bbe29b50  6 days ago     /bin/sh -c #(nop) ADD file:9474e987e88bd93248   31.46 MB
e9413ccecaa1  6 days ago     /bin/sh -c adduser -D bob                       3.955 kB
4986bf8c1536  2 weeks ago    /bin/sh -c #(nop) CMD [/bin/sh]                 0 B
ea13149945cb  2 weeks ago    /bin/sh -c #(nop) ADD file:8cf517d90fe79547c4   2.433 MB
df7546f9f060  3 months ago   /bin/sh -c #(nop) MAINTAINER Jérôme Petazzo     0 B
511136ea3c5a  19 months ago                                                  0 B

When we consider that a large application might have several hundred megabytes or more, this chown becomes very expensive.

@cyphar

This comment has been minimized.

Show comment
Hide comment
@cyphar

cyphar Jan 20, 2015

Contributor

#9934 has been opened to fix this issue (my patches were rejected).

Contributor

cyphar commented Jan 20, 2015

#9934 has been opened to fix this issue (my patches were rejected).

rafabene added a commit to rafabene/docker_tutorial that referenced this issue Feb 6, 2015

Update Dockerfile commands
I had permission issues with the centos image running on MacOS/Boot2Docker 1.4.1. It cause the javaee6angularjs.war to be copied using root ownership and 740 permission. That caused WildFly to throw a FileNotFoundException. 

The proposed changes fix that issue by placing the file under wildfly ownership. There's a docker issue opened about that issue: moby/moby#6119
@goldmann

This comment has been minimized.

Show comment
Hide comment
@goldmann

goldmann Mar 16, 2015

Contributor

This behavior really, really needs to be changed to make sure ADD uses current USER. Current way of implementing it with chown:

  1. Created 3 (sic!) unnecessary layers
  2. Makes Dockerfile ugly
  3. Is totally not intuitive.
Contributor

goldmann commented Mar 16, 2015

This behavior really, really needs to be changed to make sure ADD uses current USER. Current way of implementing it with chown:

  1. Created 3 (sic!) unnecessary layers
  2. Makes Dockerfile ugly
  3. Is totally not intuitive.
@sandric

This comment has been minimized.

Show comment
Hide comment
@sandric

sandric Apr 4, 2015

@goldmann agree on all points!

sandric commented Apr 4, 2015

@goldmann agree on all points!

@thaJeztah

This comment has been minimized.

Show comment
Hide comment
@thaJeztah

thaJeztah Apr 4, 2015

Member

This topic was discussed by the maintainers and, while they agreed that having USER specify the owner of files added by ADD / COPY would have been a better choice, changing this behavior now would be a breaking change, which would be too much of a risk.

For this reason, #9934 was created to come with alternatives. An implementation of this is created in #10775, which is currently under review.

For those interested, please follow the review/discussion on #9934 to check progress.

Member

thaJeztah commented Apr 4, 2015

This topic was discussed by the maintainers and, while they agreed that having USER specify the owner of files added by ADD / COPY would have been a better choice, changing this behavior now would be a breaking change, which would be too much of a risk.

For this reason, #9934 was created to come with alternatives. An implementation of this is created in #10775, which is currently under review.

For those interested, please follow the review/discussion on #9934 to check progress.

@duglin

This comment has been minimized.

Show comment
Hide comment
@duglin

duglin May 6, 2015

Contributor

@kostickm is working on a proposal for this.

Contributor

duglin commented May 6, 2015

@kostickm is working on a proposal for this.

@kiwenlau

This comment has been minimized.

Show comment
Hide comment
@kiwenlau

kiwenlau May 19, 2015

I think fix this problem will help to decrease images size. Specify users when ADD files is a great idea!

For example, if I ADD a binary like Hadoop, then chown it to hadoop user, the image size will increase 100+MB!

That's why I decided to install hadoop under root user:(

kiwenlau commented May 19, 2015

I think fix this problem will help to decrease images size. Specify users when ADD files is a great idea!

For example, if I ADD a binary like Hadoop, then chown it to hadoop user, the image size will increase 100+MB!

That's why I decided to install hadoop under root user:(

@borntorock

This comment has been minimized.

Show comment
Hide comment
@borntorock

borntorock Apr 27, 2017

Also, if someone wants to change the owner and group owner of the files added inside the docker image via COPY or ADD, that actually increases the size of the image by the size of the files added.

It would be great to have COPY2 so that the USER with whom we're actually copying the files inside the docker image becomes the owner and groupowner.

borntorock commented Apr 27, 2017

Also, if someone wants to change the owner and group owner of the files added inside the docker image via COPY or ADD, that actually increases the size of the image by the size of the files added.

It would be great to have COPY2 so that the USER with whom we're actually copying the files inside the docker image becomes the owner and groupowner.

@rhuss

This comment has been minimized.

Show comment
Hide comment
@rhuss

rhuss Apr 27, 2017

Contributor

I'm subscribed on this issue since maybe two years, and I'm really puzzled why no solution has been found, whatever this looks like

One of the first arguments was that the Dockerfile format is frozen. That might have been true at that time, but does not hold anymore as there as been some changes since then (like FROM ... AS or adding HEALTHCHECK)

Since the last release the option --from has been added to COPY. So there is also no reason anymore against adding options to Dockerfile keywords.

So what are the arguments against a COPY --chown <uid>:<gid> these days?

Contributor

rhuss commented Apr 27, 2017

I'm subscribed on this issue since maybe two years, and I'm really puzzled why no solution has been found, whatever this looks like

One of the first arguments was that the Dockerfile format is frozen. That might have been true at that time, but does not hold anymore as there as been some changes since then (like FROM ... AS or adding HEALTHCHECK)

Since the last release the option --from has been added to COPY. So there is also no reason anymore against adding options to Dockerfile keywords.

So what are the arguments against a COPY --chown <uid>:<gid> these days?

@attila-lendvai

This comment has been minimized.

Show comment
Hide comment
@attila-lendvai

attila-lendvai Apr 27, 2017

@thaJeztah i tried to be ironic about the developers lamenting that fixing this bug would be a breaking change. no shit, who would have thought!

just the amount of discussion that happens in the numerous threads that i encountered is a lot of time wasted, both by the developers and by the users. and all that for what? trying to protect some hypothetical users who knowingly relied on the behavior that COPY, rather surprisingly, ignores USER?

what are major version numbers for? and release notes?

if there actually exists anyone who relies on this bug then they should not upgrade to a new major release, or read the release notes.

and let's say their code is broken because they didn't read the release notes... what about the tons of users who get bitten by this every single day? maybe one outweighs the other...

attila-lendvai commented Apr 27, 2017

@thaJeztah i tried to be ironic about the developers lamenting that fixing this bug would be a breaking change. no shit, who would have thought!

just the amount of discussion that happens in the numerous threads that i encountered is a lot of time wasted, both by the developers and by the users. and all that for what? trying to protect some hypothetical users who knowingly relied on the behavior that COPY, rather surprisingly, ignores USER?

what are major version numbers for? and release notes?

if there actually exists anyone who relies on this bug then they should not upgrade to a new major release, or read the release notes.

and let's say their code is broken because they didn't read the release notes... what about the tons of users who get bitten by this every single day? maybe one outweighs the other...

@dvdgsng

This comment has been minimized.

Show comment
Hide comment
@dvdgsng

dvdgsng May 9, 2017

So, this is considered to be a breaking change while renaming the whole project is not?

dvdgsng commented May 9, 2017

So, this is considered to be a breaking change while renaming the whole project is not?

@goldmann

This comment has been minimized.

Show comment
Hide comment
@goldmann

goldmann May 10, 2017

Contributor

This was commited a few months ago: 0725045. I'll leave it just here.

Contributor

goldmann commented May 10, 2017

This was commited a few months ago: 0725045. I'll leave it just here.

@DavidAntliff

This comment has been minimized.

Show comment
Hide comment
@DavidAntliff

DavidAntliff May 11, 2017

Well, just to vent my frustration - this just caught me out (and I've been using Docker for a year now). How is this still a problem?

DavidAntliff commented May 11, 2017

Well, just to vent my frustration - this just caught me out (and I've been using Docker for a year now). How is this still a problem?

@softwareplumber

This comment has been minimized.

Show comment
Hide comment
@softwareplumber

softwareplumber May 25, 2017

Wow. I'm a complete Docker newb and just ran into this one. From my virgin perspective, I absolutely expected ADD and COPY to respect USER. That they don't was a source of considerable astonishment that increased exponentially when I saw just how long ago this issue was raised and how simple the apparent fix is. I don't generally post to zombie threads, but felt obliged to add my insignificant voice to the general chorus of bafflement expressed here.

softwareplumber commented May 25, 2017

Wow. I'm a complete Docker newb and just ran into this one. From my virgin perspective, I absolutely expected ADD and COPY to respect USER. That they don't was a source of considerable astonishment that increased exponentially when I saw just how long ago this issue was raised and how simple the apparent fix is. I don't generally post to zombie threads, but felt obliged to add my insignificant voice to the general chorus of bafflement expressed here.

@italomaia

This comment has been minimized.

Show comment
Hide comment
@italomaia

italomaia Jun 3, 2017

This issue was closed because ... ?

italomaia commented Jun 3, 2017

This issue was closed because ... ?

@ehernandez-xk

This comment has been minimized.

Show comment
Hide comment
@ehernandez-xk

ehernandez-xk Jun 8, 2017

As a workaround using Alpine for me it was:

  • COPY xfile location/xfile
  • RUN adduser -S xuser
  • RUN chown xuser -R location/xfile
  • USER xuser

ehernandez-xk commented Jun 8, 2017

As a workaround using Alpine for me it was:

  • COPY xfile location/xfile
  • RUN adduser -S xuser
  • RUN chown xuser -R location/xfile
  • USER xuser
@borntorock

This comment has been minimized.

Show comment
Hide comment
@borntorock

borntorock Jun 8, 2017

@ehernandez-xk Hey, Looks like you didn't read the previous comments. Though this seems to be a workaround, but this is going to increase your image size by the size of your xfile.

what if incase the files I'm copying inside the docker image is of 1Gb. I can't afford to have my image size increased by 1GB.

borntorock commented Jun 8, 2017

@ehernandez-xk Hey, Looks like you didn't read the previous comments. Though this seems to be a workaround, but this is going to increase your image size by the size of your xfile.

what if incase the files I'm copying inside the docker image is of 1Gb. I can't afford to have my image size increased by 1GB.

@borntorock

This comment has been minimized.

Show comment
Hide comment
@borntorock

borntorock Jun 8, 2017

@italomaia Not sure, why this issue was closed?

@thaJeztah This is not fixed.

borntorock commented Jun 8, 2017

@italomaia Not sure, why this issue was closed?

@thaJeztah This is not fixed.

@robhaswell

This comment has been minimized.

Show comment
Hide comment
@robhaswell

robhaswell Jun 8, 2017

what if incase the files I'm copying inside the docker image is of 1Gb. I can't afford to have my image size increased by 1GB.

It also may take an unacceptably long amount of time.

robhaswell commented Jun 8, 2017

what if incase the files I'm copying inside the docker image is of 1Gb. I can't afford to have my image size increased by 1GB.

It also may take an unacceptably long amount of time.

@italomaia

This comment has been minimized.

Show comment
Hide comment
@italomaia

italomaia Jun 8, 2017

Hey @jessfraz is the reason why this issue was closed still valid?

italomaia commented Jun 8, 2017

Hey @jessfraz is the reason why this issue was closed still valid?

@softwareplumber

This comment has been minimized.

Show comment
Hide comment
@softwareplumber

softwareplumber Jun 8, 2017

softwareplumber commented Jun 8, 2017

@DeRain

This comment has been minimized.

Show comment
Hide comment
@DeRain

DeRain Jun 12, 2017

@ehernandez-xk @borntorock it seems we could use --squash as a workaround simultaneously with chown

DeRain commented Jun 12, 2017

@ehernandez-xk @borntorock it seems we could use --squash as a workaround simultaneously with chown

@karneaud

This comment has been minimized.

Show comment
Hide comment
@karneaud

karneaud commented Jun 19, 2017

+1

@softwareplumber

This comment has been minimized.

Show comment
Hide comment
@softwareplumber

softwareplumber Jun 23, 2017

softwareplumber commented Jun 23, 2017

@thiagowfx

This comment has been minimized.

Show comment
Hide comment
@thiagowfx

thiagowfx Jul 11, 2017

TL;DR non-intuitive behavior; use chown -R to set / enforce permissions after ADD or COPY if you want them to be other than root; USER has no effect on file permissions whatsoever.

thiagowfx commented Jul 11, 2017

TL;DR non-intuitive behavior; use chown -R to set / enforce permissions after ADD or COPY if you want them to be other than root; USER has no effect on file permissions whatsoever.

@paulp

This comment has been minimized.

Show comment
Hide comment
@paulp

paulp Jul 11, 2017

@thiagowfx Your tl;dr summarizes a little too aggressively - it bears mentioning that this will double the size of your docker image.

paulp commented Jul 11, 2017

@thiagowfx Your tl;dr summarizes a little too aggressively - it bears mentioning that this will double the size of your docker image.

@softwareplumber

This comment has been minimized.

Show comment
Hide comment
@softwareplumber

softwareplumber Jul 11, 2017

softwareplumber commented Jul 11, 2017

@DavidAntliff

This comment has been minimized.

Show comment
Hide comment
@DavidAntliff

DavidAntliff Jul 11, 2017

It's typically worse than just a chown. Because you're likely to be "running" as a non-root user (which is why you probably encountered this issue in the first place), you need to change the root user first, and then switch back to your non-root user afterwards. It typically results in four commands:

COPY ...
USER root
RUN chown -R ...
USER <original>

It can be improved by allowing your user to run sudo /bin/chown in /etc/sudoers (one command) but that has a bad smell to it in my opinion (not to mention a security hole if you are locking the container down in other ways), so you add another line to remove it later (and then the next layer adds it back again to do the same thing...)

Surely something like the following is better for everyone?

COPY --owner user.group

Can the Docker Engine plugin interface be used to implement new commands such as this?

DavidAntliff commented Jul 11, 2017

It's typically worse than just a chown. Because you're likely to be "running" as a non-root user (which is why you probably encountered this issue in the first place), you need to change the root user first, and then switch back to your non-root user afterwards. It typically results in four commands:

COPY ...
USER root
RUN chown -R ...
USER <original>

It can be improved by allowing your user to run sudo /bin/chown in /etc/sudoers (one command) but that has a bad smell to it in my opinion (not to mention a security hole if you are locking the container down in other ways), so you add another line to remove it later (and then the next layer adds it back again to do the same thing...)

Surely something like the following is better for everyone?

COPY --owner user.group

Can the Docker Engine plugin interface be used to implement new commands such as this?

@italomaia

This comment has been minimized.

Show comment
Hide comment
@italomaia

italomaia Jul 11, 2017

There is already a PR for this particular problem, but it is closed, waiting for some discussions to end. #28499

italomaia commented Jul 11, 2017

There is already a PR for this particular problem, but it is closed, waiting for some discussions to end. #28499

@andyburton

This comment has been minimized.

Show comment
Hide comment
@andyburton

andyburton Jul 17, 2017

This is extremely painful when having to do an npm install with COPY followed by chown, and combined with the Mac filesystem performance issues! A simple COPY with chown would make a significant difference.

andyburton commented Jul 17, 2017

This is extremely painful when having to do an npm install with COPY followed by chown, and combined with the Mac filesystem performance issues! A simple COPY with chown would make a significant difference.

@kaikuchn

This comment has been minimized.

Show comment
Hide comment
@kaikuchn

kaikuchn Jul 31, 2017

To save those who are interested in seeing this fixed a lot of time: here is the current attempt to implement a fix.

kaikuchn commented Jul 31, 2017

To save those who are interested in seeing this fixed a lot of time: here is the current attempt to implement a fix.

@sergeytrasko sergeytrasko referenced this issue Sep 26, 2017

Merged

Docker support #6 #17

5 of 5 tasks complete
@JPvRiel

This comment has been minimized.

Show comment
Hide comment
@JPvRiel

JPvRiel Oct 23, 2017

Wow. I'm a complete Docker newb and just ran into this one. From my virgin perspective, I absolutely expected ADD and COPY to respect USER.

Agree, this is not intuitive. USER was added to set the context for RUN and CMD instructions, and so one might assume it's more or less like an su USER and should also apply to COPY/ADD.

However, under the hood, docker is running itself and the build as root? So if root is the process doing the copy, then the resulting file is also owned by root. E.g. In an ordinary shell, when a cp command is executed, the UNIX permissions of the process running the copy command is used by default (unless special options are used). So docker implemented a pseudo user context switch, but only for some instructions and not others? This boils down to being somewhat inconsistent. Its confusing to have a user context only imply half the time...

JPvRiel commented Oct 23, 2017

Wow. I'm a complete Docker newb and just ran into this one. From my virgin perspective, I absolutely expected ADD and COPY to respect USER.

Agree, this is not intuitive. USER was added to set the context for RUN and CMD instructions, and so one might assume it's more or less like an su USER and should also apply to COPY/ADD.

However, under the hood, docker is running itself and the build as root? So if root is the process doing the copy, then the resulting file is also owned by root. E.g. In an ordinary shell, when a cp command is executed, the UNIX permissions of the process running the copy command is used by default (unless special options are used). So docker implemented a pseudo user context switch, but only for some instructions and not others? This boils down to being somewhat inconsistent. Its confusing to have a user context only imply half the time...

@thaJeztah

This comment has been minimized.

Show comment
Hide comment
@thaJeztah

thaJeztah Oct 24, 2017

Member

This feature has now been implemented through an optional --chown flag on ADD and COPY through pull request: #34263

The feature is included in Docker 17.09 and up, and allows you to do;

ADD --chown=someuser:somegroup /foo /bar
COPY --chown=someuser:somegroup /foo /bar

Or other combinations of user/group name (or ID);

--chown=someuser:123
--chown=anyuser:anygroup
--chown=1001:1002
--chown=333:agroupname

There are two additional feature requests in this area;

  • #35018 ("Allow COPY command's --chown to be dynamically populated via ENV or ARG")
  • #34819 ("Proposal: Add --chmod flag to ADD/COPY commands (analogous to --chown)")

Given that the original problem was addressed (the implementation is different from the one proposed in this issue, you can read the discussion in #9934 and #9934 (comment) for more background on that), I'm locking the discussion on this issue to prevent it from collecting other (possibly unrelated) comments.

If you arrive on this issue because this feature is not working as expected, or you think other enhancements can be made; please open a new issue instead so that it can be tracked separately (feel free to add a link to this issue if you think it's relevant).

Member

thaJeztah commented Oct 24, 2017

This feature has now been implemented through an optional --chown flag on ADD and COPY through pull request: #34263

The feature is included in Docker 17.09 and up, and allows you to do;

ADD --chown=someuser:somegroup /foo /bar
COPY --chown=someuser:somegroup /foo /bar

Or other combinations of user/group name (or ID);

--chown=someuser:123
--chown=anyuser:anygroup
--chown=1001:1002
--chown=333:agroupname

There are two additional feature requests in this area;

  • #35018 ("Allow COPY command's --chown to be dynamically populated via ENV or ARG")
  • #34819 ("Proposal: Add --chmod flag to ADD/COPY commands (analogous to --chown)")

Given that the original problem was addressed (the implementation is different from the one proposed in this issue, you can read the discussion in #9934 and #9934 (comment) for more background on that), I'm locking the discussion on this issue to prevent it from collecting other (possibly unrelated) comments.

If you arrive on this issue because this feature is not working as expected, or you think other enhancements can be made; please open a new issue instead so that it can be tracked separately (feel free to add a link to this issue if you think it's relevant).

@moby moby locked and limited conversation to collaborators Oct 24, 2017

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