-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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
Match Container's User and Group to Host #49962
Match Container's User and Group to Host #49962
Conversation
Instead of running the web service as `root` and the CLI service as `33:33`, we should be running them as the host user. By doing this we ensure ownership parity in mounted folders on platforms where having different owners would result in permission issues.
Hey @defunctl, @Luc45, and @eliot-akira! Given the wide reach of this pull request, I was wondering if you folks might take a look at this and try it out locally? I think this will solve all of our existing permission problems in a minimally invasive way. |
const hostUser = os.userInfo(); | ||
const uid = ( hostUser.uid === -1 ? 0 : hostUser.uid ).toString(); | ||
const gid = ( hostUser.gid === -1 ? 0 : hostUser.gid ).toString(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As per Node's documentation, on Windows the uid
and gid
is -1
. I think this only happens with a process.platform
of win32
. If you're using WSL you will realistically be running commands inside the container, so, this is more of an edge-case where they have Node installed on Windows.
The question I have is whether or not this breaks anything. I'm curious about what kind of permission magic takes place when going mounting from Windows -> Docker instead of WSL -> Docker. If it works anything like macOS, I would wager that having everything owned by root
doesn't matter.
I noticed this wp-content and wp-config.php are under different users and groups. Not sure if that's a problem!
Also, curious if this code is necessary any more: gutenberg/packages/env/lib/wordpress.js Lines 175 to 181 in 4dbc1a6
So far this is working fine on macOS, but that's expected 😅 I'll try to test on Windows as well. |
This is probably because the These problems shouldn't happen on Linux because it uses
It probably isn't, actually. Let's wait for some further verification on whether or not this pull request works, and if it does, we can take a look at other things like this that may not be necessary anymore. |
I hadn't done that. Potentially worth mentioning in the changelog if it's necessary |
I haven't tested this yet, but the logic seems sound. This is similar to what fixuid does. One thing that it does and I'm not seeing here is something like |
Thanks @Luc45, |
I think it might be necessary on macOS @noahtallen, but, I'm not sure if it is elsewhere. On macOS the permissions in the containers are unique to them, so, they'll retain whatever permissions they had prior. With Linux, since the permissions are unified, they probably won't need to make any changes. Assuming that it works in Linux as-is without regenerating the environment, I don't think folks need to do anything. If regenerating works, we should test a pre-PR |
Sounds good, I'll take it for a spin (tentatively tomorrow) and report back |
I used
It looks like the changes in this PR had the desired effect. There was no longer a need to change any permissions and everything worked exactly as expected. None of the permission oddities we see on macOS are present and everything has exactly what we expected it to. |
I set up WSL2 on my Windows machine and tested this out there. I confirmed that on I've also confirmed that uploads operate the same way. Now that I've got this environment set up, I'll come back and try out removing the permission change for uploads. This might be it! |
With the changes in this pull request we no longer need to do this.
I mean, wp-env still seemed to work ok without destroying it, but maybe I should stress test it more :P |
This will ensure things like `wp plugin install` have a directory to use as a cache. Anything else can now refer to the home directory for the same purpose.
Some of our `docker-compose run` actions weren't removing the container after being executed. This was breaking `wp-env destroy` becuase of the volumes that were in-use.
Thank you again for such comprehensive feedback @eliot-akira. This has given me a great deal of confidence that we can release this change without destroying everyone's environment. It looks like we will just need folks to destroy their current environment. Once they've done that, it will work as-expected. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the phpunit test failures could potentially be related: https://github.com/WordPress/gutenberg/actions/runs/4802349358/jobs/8545703892?pr=49962#step:11:183
Or at the very least, the changes in the PR might be uncovering an issue. I feel like these were also flaky in the PR last week, and the phpunit ones normally shouldn't be that flaky 🤔
packages/env/README.md
Outdated
|
||
```sh | ||
wp-env start --debug | ||
``` | ||
|
||
`wp-env` will output its config which includes `dockerComposeConfigPath`. | ||
`wp-env` will output its config which includes `dockerComposeConfigPath`: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This doc section is actually out of date now that we have npx install-path! We could probably change the entire thing to say that you can just cd $(npx wp-env install-path)
and then see all the generated config files
Co-authored-by: Noah Allen <[email protected]>
Some documentation thoughts @noahtallen:
|
Debian stretch was just removed from deb.debian.org and moved to the archive repository. This commit changes the sources so that, on stretch, the apt-get update won't break.
@@ -203,6 +203,14 @@ function wordpressDockerFileContents( image, config ) { | |||
|
|||
return `FROM ${ image } | |||
|
|||
# Update apt sources for archived versions of Debian. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I might also add a comment linking to that stack overflow thread for a bit of extra context
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This isn't a bad idea. Given that it's a better source of truth, I've instead linked to the Debian mailing list record of the change.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Alright, let's give this a shot!
Amazing work - thank you @ObliviousHarmony, from all of us who will benefit from this improvement. |
@ObliviousHarmony, could you confirm if this PR should have fixed what @shashwatahalder01 has reported in #50538 ? Thank you! |
Hi @mrfoxtalbot, No, this behavior is expected without appropriate configuration. As per the documentation, they will need to add a |
Hey, @ObliviousHarmony! I know it's been a while since this PR, but do you remember what you meant by this? coreMount, // Must be first because of some operations later that expect it to be! — found in Which operations later rely on |
What?
This pull request changes some of the permissions for
wp-env
containers in order to ensure parity with the host operating system.Why?
By using the host's user and group we are able to make sure the host and containers are all acting as the same owner for files and folders. This ensures files created by any of them are readable and writeable by the rest. For instance,
wp rewrite structure '/%postname%/' --hard
in thecli
container will create a.htaccess
file that thewordpress
container is able to read.Closes #22515, #45592, #49373, and #28201
How?
We add the current host user to the
wordpress
andtests-wordpress
containers using the sameuid
andgid
from the host. We also use theAPACHE_RUN_USER
andAPACHE_RUN_GROUP
environment variables so that the web server will run as the host user too. Lastly, when usingwp-env run
we use the host user that we created on the container.Thanks to #42826 we can be sure that the entire contents of our WordPress installation is mounted. This is good because it means we don't have to change the permissions of any files or folders to get this to work. The end result is that on operating systems where the distinction matters, the owner of these files is the same everywhere.
Testing Instructions
wp-env
is a good indicator that nothing has broken.npm run env start
locally and confirm that it builds the container. If you already have one, make sure to usenpm run env start --update
so that the new Dockerfile is used.npm run env run wordpress ls -la
and confirm that the files are owned by your current user. On macOS the ownership seemed oddly flaky at times, but, it doesn't matter because of the way the mounting works. I'm not sure if it does this on Linux, but, someone can test 😄npm run env run cli ls -la
and confirm that the files are still owned by your current user. The name will be missing, but, the rawuid
is a good indicator of the difference made here.npm run env run wordpress ls -la wp-content/plugins/gutenberg
and note that your current user owns all of the files and folders here.wp-admin
in the container and install a plugin via the UI. It should work.wp-cli.yml
file in/var/www/html
with the content:npm run env run cli wp rewrite structure '/%postname%/' --hard
. Usenpm run env run cli ls -la
to confirm that a.htaccess
file was created as expected.Given the opportunity for this PR to go wrong, I would suggest trying anything else that you can think of!