Skip to content
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

On Linux Containers Expect UID/GID of 1000 Otherwise Cause Permissions Trouble #155

Open
davidalger opened this issue May 22, 2020 · 8 comments
Labels
enhancement New feature or request up for grabs Extra attention is needed
Milestone

Comments

@davidalger
Copy link
Collaborator

On most Linux systems (and inside Docker Desktop VM on macOS) the default UID/GID of 1000 is used for the first non-system account created. Due to this, the fpm containers Warden uses tie the www-data user to UID 1000 and GID 1000 so that permissions will work. This is inflexible and will not work, for example, where the user account on the Linux environment used by a developer uses a non-1000 UID.

@aepod passed along the following script as a possible reference point on how to achieve solving this inflexibility in the entrypoint scripts: https://github.com/sudo-bmitch/run-as-user/blob/master/entrypoint.sh

In order to make the containers used more flexible, the stuff in the Dockerfile setting up the www-data user will need to be updated and/or moved to the entrypoint: https://github.com/davidalger/warden/blob/develop/images/php-fpm/Dockerfile#L35-L45 and two places in existing entrypoint which will need to be made flexible: https://github.com/davidalger/warden/blob/develop/images/php-fpm/context/docker-entrypoint

@davidalger davidalger added the enhancement New feature or request label May 22, 2020
@davidalger
Copy link
Collaborator Author

Stumbled across the following used by code-server images and it looks potentially very useful here: https://github.com/boxboat/fixuid

@kenbradleywhite
Copy link

Hey, I'm encountering exactly this issue as my host user is UID/GID 1002.

I'm working around this every time I spin up the containers by bashing into the PHP container and running:

sudo groupmod -g 1002 www-data
sudo usermod -u 1002 www-data

Once I exit and bash back in, the commands work with the right permissions

But because PHP-FPM itself is already running, that's still running as uid 1000 so I still need to fight with permissions.

Refreshing static content on Magento requires:

sudo rm -rf pub/static/frontend/* var/view_preprocessed/*; bin/magento cache:clean; bin/magento s:s:d en_GB -f; sudo chown -R www-data:www-data pub/static/; sudo chmod -R 777 pub/static/

I have two questions:

  • Is there a plan to resolve this problem with Warden?
  • Is there a workaround I can apply to make sure the container is started as user 1002, even if I have to hardcode this?

@davidalger
Copy link
Collaborator Author

Is there a plan to resolve this problem with Warden?

Eventually, yes. :) It's going to take some critical thinking through image changes, and possibly some other things to ensure it doesn't only solve the issue on Linux, but maintains existing functionality on Mac OS environments. There is no ETA however, as I haven't found the time to dedicate to resolving it yet. I may take a renewed look at it if more folks begin to run into this being the only big show stopper issue for them.

@stale
Copy link

stale bot commented Dec 12, 2020

Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward?

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

@stale stale bot added the stale label Dec 12, 2020
@stale stale bot closed this as completed Dec 19, 2020
@davidalger davidalger reopened this Feb 13, 2021
@stale stale bot removed the stale label Feb 13, 2021
@davidhiendl
Copy link
Contributor

davidhiendl commented May 6, 2021

This problem is even more severe if you don't have o+rX permissions on files as nginx seems to run with uid/gid 101.
This requires me to constantly update permissions on files to o+rX when triggering stylesheet compilation (gulp sass).

Would you accept a pull request with an update to the nginx container to run with the same pid/gid as php-nginx (1000)?

Edit: A simple workaround seems to be to create a new user with uid/gid 1000 and add nginx to this group:

docker exec -ti envname_nginx_1 bash
# ...
useradd app
usermod nginx -aG app
kill 1
# ... this will result in the container dying
warden env up

Edit 2: Perhaps a general (and quite simple) workaround is to add a variable to env allowing a user/group id to be specified which php and nginx container users are added to.

@bmelman
Copy link

bmelman commented Apr 7, 2022

Considered using warden on Ubuntu but apparently this is not working. Almost all of the docker environments that also work on linux have a configurable uid/gid in a .env file, and using these to set www-data to configured uid/gid.
nice examples here: https://jtreminio.com/blog/running-docker-containers-as-current-host-user/
I ended up with using this in Dockerfile for php/nginx/cli:

ARG USER_ID
ARG GROUP_ID

RUN if [ ${USER_ID:-0} -ne 0 ] && [ ${GROUP_ID:-0} -ne 0 ]; then \
    userdel -f www-data &&\
    if getent group www-data ; then groupdel www-data; fi &&\
    groupadd -g ${GROUP_ID} www-data &&\
    useradd -l -u ${USER_ID} -g www-data www-data \
;fi

@viral8421
Copy link

I also have the same issue when I make the environment down or up.

So what I'll do spin up the environment with warden env up command I'll firstly run the below command to make uid as the host system.

sudo usermod -u 1001 www-data
sudo groupmod -g 1001 www-data

After that i'll finally run the chown permission fix command to make same uid/gid for host and docker php-fpm user

and then I'll only use warden env stop and warden env start to reuse the same containers.

@davidalger is there any quick fix you might have that we can implement like with .warden/warden-env.yml also I've not configured the rootless method for docker can it help me?

@navarr navarr added this to the Warden 1.0.0 milestone Dec 9, 2022
@navarr navarr modified the milestones: Warden 1.0.0, Warden 1.1.0 Mar 8, 2023
@navarr navarr added the up for grabs Extra attention is needed label Mar 21, 2023
toonvd pushed a commit to toonvd/warden that referenced this issue Sep 23, 2023
toonvd pushed a commit to toonvd/warden that referenced this issue Sep 23, 2023
@ortoDev
Copy link

ortoDev commented Nov 29, 2023

It's still an issue on Ubuntu 22.04

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request up for grabs Extra attention is needed
Projects
Status: 🆕 New
Development

No branches or pull requests

7 participants