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

UID mismatch causes permission issues #8

Closed
paddy-hack opened this Issue Mar 12, 2017 · 4 comments

Comments

Projects
None yet
3 participants
@paddy-hack

paddy-hack commented Mar 12, 2017

Hi, I was following through your really nice article and that went swell. Next, I tried repeating this with node:6.10.0. I checked out 01-bootstrapping and modified the Dockerfile's FROM statement to use node:6.10.0. Ran docker-compose up without a hitch. Next

~/docker-chat-demo$ docker-compose run --rm chat /bin/bash
app@13fbfb3d043f:~/chat$ npm init --yes
npm info it worked if it ends with ok
npm info using npm@3.7.5
npm info using node@v6.10.0
npm info init written successfully
npm ERR! Linux 3.16.0-4-amd64
npm ERR! argv "/usr/local/bin/node" "/usr/local/bin/npm" "init" "--yes"
npm ERR! node v6.10.0
npm ERR! npm  v3.7.5
npm ERR! path /home/app/chat/package.json
npm ERR! code EACCES
npm ERR! errno -13
npm ERR! syscall open

npm ERR! Error: EACCES: permission denied, open '/home/app/chat/package.json'
npm ERR!     at Error (native)
npm ERR!  { Error: EACCES: permission denied, open '/home/app/chat/package.json'
npm ERR!     at Error (native)
npm ERR!   errno: -13,
npm ERR!   code: 'EACCES',
npm ERR!   syscall: 'open',
npm ERR!   path: '/home/app/chat/package.json' }
npm ERR! 
npm ERR! Please try running this command again as root/Administrator.
npm ERR! Linux 3.16.0-4-amd64
npm ERR! argv "/usr/local/bin/node" "/usr/local/bin/npm" "init" "--yes"
npm ERR! node v6.10.0
npm ERR! npm  v3.7.5
npm ERR! path npm-debug.log.3292290334
npm ERR! code EACCES
npm ERR! errno -13
npm ERR! syscall open

npm ERR! Error: EACCES: permission denied, open 'npm-debug.log.3292290334'
npm ERR!     at Error (native)
npm ERR!  { Error: EACCES: permission denied, open 'npm-debug.log.3292290334'
npm ERR!     at Error (native)
npm ERR!   errno: -13,
npm ERR!   code: 'EACCES',
npm ERR!   syscall: 'open',
npm ERR!   path: 'npm-debug.log.3292290334' }
npm ERR! 
npm ERR! Please try running this command again as root/Administrator.

npm ERR! Please include the following file with any support request:
npm ERR!     /home/app/chat/npm-debug.log

Thing is, the newer node images have a node user account (UID 1000). Creating a new app user (gets UID 1001) is fine, but when you run with that this no longer matches the UID outside the container. It looks to me that your article relied on the fact that your UID outside the container is the same as the UID of the user inside the container. You should probably mention that (and point to a fix if you know of one 😉).

@jdleesmiller

This comment has been minimized.

Show comment
Hide comment
@jdleesmiller

jdleesmiller Mar 19, 2017

Owner

Thanks for reporting this and sorry for the slow response. That's a good point. I've now made a note about this assumption in the article.

I've hit this UID mismatch problem a few times in other contexts, but I have never come up with any particularly good solution. When I create the app user in the container, I set its UID to match what's on the host, where possible. That's terrible for portability, however, and as you found, quite fragile.

There is an issue on docker for this, moby/moby#7198, which it seems has been closed as fixed with moby/moby#20262, but it does not seem that it is actually fixed, given comments in e.g. docker/compose#3715.

Owner

jdleesmiller commented Mar 19, 2017

Thanks for reporting this and sorry for the slow response. That's a good point. I've now made a note about this assumption in the article.

I've hit this UID mismatch problem a few times in other contexts, but I have never come up with any particularly good solution. When I create the app user in the container, I set its UID to match what's on the host, where possible. That's terrible for portability, however, and as you found, quite fragile.

There is an issue on docker for this, moby/moby#7198, which it seems has been closed as fixed with moby/moby#20262, but it does not seem that it is actually fixed, given comments in e.g. docker/compose#3715.

@paddy-hack

This comment has been minimized.

Show comment
Hide comment
@paddy-hack

paddy-hack Mar 20, 2017

Thanks for the pointers. Guess I'll be going through the documentation to see if something useful has popped into existence. Stuff changes so fast 😩

BTW, I've been wondering whether --userns might be of use assuming I set up subuid and subgid suitably.

In the mean time I'm working around by simply editing package.json manually outside of the container after the failed npm install.

paddy-hack commented Mar 20, 2017

Thanks for the pointers. Guess I'll be going through the documentation to see if something useful has popped into existence. Stuff changes so fast 😩

BTW, I've been wondering whether --userns might be of use assuming I set up subuid and subgid suitably.

In the mean time I'm working around by simply editing package.json manually outside of the container after the failed npm install.

@stcroppe

This comment has been minimized.

Show comment
Hide comment
@stcroppe

stcroppe Sep 7, 2017

I think the easier way is to use the groups assignment. The box uses uid:1001, gid:1001 and groups:1001 - I created a developer group with the id 1001 and assigned myself to the developer group and that seemed to do the trick.
developer group

stcroppe commented Sep 7, 2017

I think the easier way is to use the groups assignment. The box uses uid:1001, gid:1001 and groups:1001 - I created a developer group with the id 1001 and assigned myself to the developer group and that seemed to do the trick.
developer group

@paddy-hack

This comment has been minimized.

Show comment
Hide comment
@paddy-hack

paddy-hack Sep 9, 2017

Using the gid approach assumes that you have a umask that doesn't remove group write permission, i.e. something like 0002. The default for most setups I've seen is 0022 so users would need to change it for this to work. I can imagine some people would not like to have it set to 0002 by default but it is fairly easily changed in one's .profile.

paddy-hack commented Sep 9, 2017

Using the gid approach assumes that you have a umask that doesn't remove group write permission, i.e. something like 0002. The default for most setups I've seen is 0022 so users would need to change it for this to work. I can imagine some people would not like to have it set to 0002 by default but it is fairly easily changed in one's .profile.

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