Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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 should probably be moved to the above if when the file is created, right ?
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.
no. testing it, the docker daemon resets the group each start. so it needs to be done each time the container starts.
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.
@williamdes What do you mean? Can we add this owner change to close a 5 years old issue? Don't get me wrong, but this will help a lot of people :)
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.
Sure, I am very interested too in closing this old bug
What bugs me is why can we not change the file owner at build time or create file time instead of repeatingly changing the group
In rootless mode this makes no sense to me: how a non root user would change the group of a file root owned??
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.
Security is exactly the point, not to change the file to be owned by www- user. In docker rootless mode, the file will be created inside the Container as running user/group, which would be root/root. This is safe, but cannot be read by phpmyadmin, as the user+group of apache would be www.
Setting the user to be www would mean giving the apache full rights to do whatever apache wants with that file, ALSO if the user would have NO RIGHTS TO WRITE to it (this is a often missunderstood feature of Linux).
The only way without using acls to give someone right to read a file without having the possibility to change it, is to not make the user own that file.
Also currently docker is a bit lazy of what groups and permissions are, so unfortunatelly it resets the group every time the container starts.
I don't see another way, if someone does, we could use it. But by now, rootless is only not working because of that.
So i would suppose to take that fix and make rootless work and after that if there are further problems - investigate seperately. only my two cents :)
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.
@J0WI do you have knowledge of other techniques?
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.
Here is a common pattern:
If you mount the config anyway, you can mount it read-only: https://docs.docker.com/storage/bind-mounts/#use-a-read-only-bind-mount
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.
Currently, there is no mount an no config file. The file is part of running application, created inside the container itself at first start, giving an unique secret key for each instance.
This could be added, to maybe improve fpm/alpine compatibility in the future, but currently I don't see fpm images with phpmyadmin:
if [[ "$1" == apache2* ]] || [ "$1" = 'php-fpm' ]; then
...
group="${APACHE_RUN_GROUP:-www-data}"
...
As written above, user should stay root, group should he changed inside the container, so that for the host (running rootless, having umask 0007) the file will remain only read/writeable to the docker user and in the container file will only be changeable by root and only readable by Apache.
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.
How do you define the umask ?
Reading moby/moby#19189 it seems to not be supported by Docker.
Also, please see: #187 (comment)
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.
Well yes it is not by Docker itself. For my testing i have host facl set to:
While those x are X more precisely (which makes only directories X, not files), making the umask 0007 effectively.
My service has no umask set in docker.service, only my user has a ~./bashrc. Looks like docker will use the facl ones even in container itself.
So /etc/phpmyadmin/config.secret.inc.php will get 660 when created in entrypoint which is basically the wanted - while secure - default for new files as new files are usually created by the service that needs the file.
Only that file is created by root (in entrypoint) and should be readable by www-data later.
We are in entrypoint.sh. Files created here will get root:root by default and it seems that after new start of the container the group is reset again. So the (running) root- user may give the file the right to be readable by the www-data user of the service.
Also after reading #187 (comment) i don't see any reason for not doing this pull.