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

Node container GID and UID not matching local user's on Ubuntu #1240

Closed
agilec-paul opened this Issue Oct 9, 2018 · 12 comments

Comments

Projects
None yet
4 participants
@agilec-paul
Copy link

agilec-paul commented Oct 9, 2018

Bug Report

Tell us about your setup

What is your lando version and operating system?
v3.0.0-rc.1 on Ubuntu 18.04

Tell us about your .lando.yml
The config does contain a custom image however that is not the cause of the issue as I get this problem without it too.

name: myproject # Insert the project name here in the format [client][project], i.e. oxfammain.
recipe: drupal8
config:
  xdebug: true
  webroot: web
  php: '7.0'
  conf: 
    php: .vscode/php.ini
proxy:
  mailhog:
    - mail.myproject.lndo.site
services:
  database:
    creds:
      user: database
      password: database
      database: database
  mailhog:
    type: mailhog
    hogfrom:
      - appserver
    portforward: true
  node:
    type: node:carbon
    build:
      - "if [ -d $LANDO_MOUNT/web/themes/custom/site_theme ]; then cd $LANDO_MOUNT/web/themes/custom/site_theme && yarn install --production; fi"
    overrides:
      services:
        image: agilecollective/lando-node:latest
        ports: [3070:3070] # You should change this port to something random and then update gulpconfig.js in the theme to match
tooling:
  npm:
    service: node
  yarn:
    service: node
  node:
    service: node
  gulp:
    service: node
  backstop:
    service: node

My php.ini is set only for xdebug:

[PHP]

;;;;;;;;;;;;;;;
;IMPORTANT;
;PLACE THIS FILE UNDER .vscode folder;
;SO IT DOESNT GET COMMITTED;
;;;;;;;;;;;;;;;

; Xdebug
xdebug.max_nesting_level = 256
xdebug.show_exception_trace = 0
xdebug.collect_params = 0
# Extra custom Xdebug setting for debug to work in VSCode.
xdebug.remote_enable = 1 
xdebug.remote_autostart = 1 

Tell us about the command you were running
lando rebuild or any command that would cause the node container to be rebuilt, meaning a lando start can also cause the issue.

Tell us about the error you got

The ownership permissions of my ~/.ssh folder get's changed from $User $User to $User www-data as the node container is changing the group to www-data.

-rw-r--r--  1 paul www-data   397 Jan  5  2018 id_rsa.pub

Tell us generally about your bug

Locally my UID/GID is 1000, that is expected. The appserver container returns

uid=1000(www-data) gid=1000(www-data) groups=1000(www-data)

when running id.

However running id in the node container (lando ssh node) returns:

uid=1000(www-data) gid=33(www-data) groups=33(www-data)

Which is locally is assigned to the www-data group/user. This process seems to change ownership based on the GID, changing the www-data user's GID to something else still maps my folder to 33.

Not running node does not cause this issue.

@tanc

This comment has been minimized.

Copy link
Contributor

tanc commented Oct 11, 2018

I'm also able to replicate this issue on Ubuntu 18.04 (but not on MacOS). The key part of the difference between the logs for node_1 and appserver_1 follows (full log for node_1 below):

node_1       | Remapping ownership to handle Linux docker volume sharing...
node_1       | LANDO_HOST_UID: 1000
node_1       | LANDO_HOST_GID: 1000
node_1       | Resetting www-data:www-data from 33:33 to 1000:1000
node_1       | groupmod: GID '1000' already exists
node_1       | www-data:www-data is now running as uid=1000(www-data) gid=33(www-data) groups=33(www-data)!
appserver_1  | Remapping ownership to handle Linux docker volume sharing...
appserver_1  | LANDO_HOST_UID: 1000
appserver_1  | LANDO_HOST_GID: 1000
appserver_1  | Resetting www-data:www-data from 33:33 to 1000:1000
appserver_1  | www-data:www-data is now running as uid=1000(www-data) gid=1000(www-data) groups=1000(www-data)!

For some reason in the node container the gid 1000 already exists so it can't be mapped:

groupmod: GID '1000' already exists

Full log for node_1:

node_1       | user-perms.sh kicking off as user uid=0(root) gid=0(root) groups=0(root)
node_1       | Lando ENVVARS set at
node_1       | LANDO_WEBROOT_USER: www-data
node_1       | LANDO_WEBROOT_GROUP: www-data
node_1       | LANDO_WEBROOT_UID: 33
node_1       | LANDO_WEBROOT_GID: 33
node_1       | Making sure correct user:group (www-data:www-data) exists...
node_1       | 33
node_1       | 33
node_1       | Remapping ownership to handle Linux docker volume sharing...
node_1       | LANDO_HOST_UID: 1000
node_1       | LANDO_HOST_GID: 1000
node_1       | Resetting www-data:www-data from 33:33 to 1000:1000
node_1       | groupmod: GID '1000' already exists
node_1       | www-data:www-data is now running as uid=1000(www-data) gid=33(www-data) groups=33(www-data)!
node_1       | And here. we. go.
node_1       | Scanning /user/.ssh for keys...
node_1       | Scanning /lando/keys for keys...
node_1       | Checking whether /user/.ssh/id_rsa is a private key...
node_1       | Checking whether /user/.ssh/id_rsa is formatted correctly...
node_1       | Checking whether /user/.ssh/authorized_keys is a private key...
node_1       | Ensuring permissions for /user/.ssh/id_rsa...
node_1       | Using the following keys: /user/.ssh/id_rsa
node_1       | Running command /bin/sh -c tail -f /dev/null
node_1       | user-perms.sh kicking off as user uid=0(root) gid=0(root) groups=0(root)
node_1       | Lando ENVVARS set at
node_1       | LANDO_WEBROOT_USER: www-data
node_1       | LANDO_WEBROOT_GROUP: www-data
node_1       | LANDO_WEBROOT_UID: 33
node_1       | LANDO_WEBROOT_GID: 33
node_1       | Making sure correct user:group (www-data:www-data) exists...
node_1       | 1000
node_1       | 1000
node_1       | Remapping ownership to handle Linux docker volume sharing...
node_1       | LANDO_HOST_UID: 1000
node_1       | LANDO_HOST_GID: 1000
node_1       | Resetting www-data:www-data from 33:33 to 1000:1000
node_1       | usermod: no changes
node_1       | groupmod: GID '1000' already exists
node_1       | www-data:www-data is now running as uid=1000(www-data) gid=33(www-data) groups=33(www-data)!
node_1       | And here. we. go.
node_1       | Scanning /user/.ssh for keys...
node_1       | Scanning /lando/keys for keys...
node_1       | Checking whether /user/.ssh/id_rsa is a private key...
node_1       | Checking whether /user/.ssh/id_rsa is formatted correctly...
node_1       | Checking whether /user/.ssh/authorized_keys is a private key...
node_1       | Ensuring permissions for /user/.ssh/id_rsa...
node_1       | Using the following keys: /user/.ssh/id_rsa
node_1       | Running command /bin/sh -c tail -f /dev/null
@tanc

This comment has been minimized.

Copy link
Contributor

tanc commented Oct 11, 2018

So in a node container the 1000 gid belongs to node:

cat /etc/group | grep 1000
node:x:1000:
@tanc

This comment has been minimized.

Copy link
Contributor

tanc commented Oct 11, 2018

See the carbon Dockerfile where they add the node user with uid/gid 1000: https://github.com/nodejs/docker-node/blob/526c6e618300bdda0da4b3159df682cae83e14aa/8/jessie/Dockerfile

@tanc

This comment has been minimized.

Copy link
Contributor

tanc commented Oct 11, 2018

I was able to add RUN groupmod -g 999 node && usermod -u 999 -g 999 node to our Dockerfile as we're using a custom image based off standard Node one.

BUT! This is definitely going to be a problem for other Linux users running Lando with a Node container. The result of which will be their .ssh directory will be owned by www-data group and they won't be able to ssh into any servers until they discover this has happened.

@tanc

This comment has been minimized.

Copy link
Contributor

tanc commented Oct 11, 2018

@pirog and @dustinleblanc sorry to @ you into this but I think this needs handling in Lando to avoid confused/angry Linux users before a stable 1.0 release is issued. Maybe a more robust check that the gid is available and legit before changing ownership any of the user's files?

@dustinleblanc dustinleblanc added this to the RC2 milestone Oct 11, 2018

@dustinleblanc

This comment has been minimized.

Copy link
Member

dustinleblanc commented Oct 11, 2018

@tanc no worries, I think you're likely right on this one, I've just been monstrously busy with client work. I tagged this for RC2 and put it in the backlog.

If you'd like to take a crack at the fix to speed it along you can find the user perms script here: https://github.com/lando/lando/blob/master/plugins/lando-engine/scripts/user-perms.sh

I'm not great with bash scripts so I definitely trust @serundeputy or @pirog to be wiser with how to handle this fix.

Thanks for your efforts as of late, I appreciate them!

@pirog

This comment has been minimized.

Copy link
Member

pirog commented Oct 12, 2018

@tanc agreed with @dustinleblanc here, going to move this into current sprint since there are related-ish issues there

@dustinleblanc

This comment has been minimized.

Copy link
Member

dustinleblanc commented Nov 20, 2018

I just tried to apply the user/group mod change that @tanc mentioned to one of our projects and couldn't get it to work, however, I was not doing it via a dockerfile and rather used the install_dependencies_as_root method in the lando file.

@pirog pirog self-assigned this Nov 28, 2018

@pirog

This comment has been minimized.

Copy link
Member

pirog commented Jan 24, 2019

alright, on the scene and trying to replicate

@pirog

This comment has been minimized.

Copy link
Member

pirog commented Jan 24, 2019

ok yup, i can definitely replicate this

@pirog

This comment has been minimized.

Copy link
Member

pirog commented Jan 24, 2019

Ok, i think the best solution here is to just tell Lando to hijack the node user for node services instead of trying to hijack www-data. Let me give that a shot and see if that works.

pirog added a commit that referenced this issue Jan 24, 2019

@pirog

This comment has been minimized.

Copy link
Member

pirog commented Jan 24, 2019

Alright, took a bit of finagling to get this to work but we now have a pretty easy way to address this issue if there are other images that do this
4993c36#diff-d085ef0d00dd08913651a79c71916142

This will be in RC2

@pirog pirog closed this Jan 24, 2019

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