Comments (16)
Personally I don't care if a webuser
is added or if www-data
is used, and it doesn't bother me that the default user ID might change between Debian and Alpine.
What is important for me is the ability to remap the UID and GID of whatever user is running PHP-FPM. I frequently run containers from multiple users that do not have root/sudo access, so having this control is critical to ensuring those users have permissions to directories/files that are bind-mounted into the container.
from docker-php.
I believe that regardless of whether you use webuser
, www-data
or any custom user:group or UID:GID values, problems may arise if a user run your docker image along with other containers and share directories.
Therefore, itβs best to use the default user:group of the base OS and allow users to modify it according to their project setup. Avoid hard-coding UID:GID unless youβre certain that processes in your container donβt share any data with other containers. Thatβs my personal perspective when initializing Docker containers.
from docker-php.
Personally I would prefer to use the defaults. I had been trying to switch our Silverstripe sites which are using default PHP images to use the serversideup v2 images and it created a bit of a headache trying to change the user or convert mounted file system permissions.
Alternatively if the default was changed, an option to revert back to defaults or set the PHP user via an env variable would be handy.
Love the work you doing!
from docker-php.
i prefer to use the defaults too with the ability to change the UID/GID
from docker-php.
@jaydrogers As you mentioned, the following command is not working ...
command: ["su", "www-data", "-c", "php artisan schedule:work"]
So, how i can run the horizon or task scheduler?
I got it working by implementing this in my dockerfile #287
from docker-php.
πͺ Big Update
We have a PR ready for testing that will dramatically improve container security and developer experience:
π Long story, short
- We will be sticking with the native UID/GID of
www-data
(33:33
for Debian and82:82
for Alpine) - There will NOT be any shell privileges for
www-data
by default
π Please help test this
Everything is documented on the PR on how to test:
- We have pre-built images for you to test (see the PR for more details)
- We also dramatically improved the documentation with the containers moving to be unprivileged by default (get the preview URL from the PR)
There is also a significant improvement with running Laravel Queues, Schedulers, etc in the PR's Preview Documentation site.
We will merge this big change soon if we get good feedback π π
Check the PR for more details β
from docker-php.
Thanks for your feedback everyone. I am leaning to NOT add a webuser
like I did before and just use the system defaults of www-data
.
π My new, but related question
- What about adding shell privileges to
www-data
?
This is why I created webuser
before, so I could have a dedicated user.
Use case
It's nice to have shell when I need to run php artisan
commands as the app user. Here you can see we currently do not have this in the beta.
Is adding a shell to www-data a good idea? Do you feel it is secure to do this? Thoughts?
from docker-php.
Think of www-data
like a cafeteria worker at school. Their job is just to serve food in the cafeteria - they don't need access to other parts of the school. Giving www-data
a shell would be like giving the cafeteria worker keys to the whole school!
Even if the cafeteria worker is honest, now a bad guy could trick or bribe them to get the keys and access to the whole school. Or if the cafeteria worker makes a mistake, the bad guy could get the keys and make a copy.
The www-data
user is similar - its job is just to show web pages. It doesn't need access to run programs or files on the server. Giving it a shell lets bad guys access the whole server if they compromise a web app.
It's safer to give users and programs only the access they absolutely have to have. That way there's less risk if one gets compromised. The cafeteria worker doesn't need keys to the chem lab, and www-data
doesn't need a shell. Limiting access limits damage if something goes wrong!
from docker-php.
Thanks @shinsenter! I greatly appreciate your feedback. You and I are definitely on the same page. I highly respect your opinion and I love the analogy too π
So in finding the balance of security and user experience:
- What is the most secure approach in running
php artisan
commands aswww-data
if we keep using the default operating system user?
With PHP requiring root
to bring up services for things like fpm-nginx, it turns into a Docker permission nightmare π
from docker-php.
One of approaches for running php artisan
commands as www-data
is setting the setuid bit on the artisan
file so it always runs as www-data
. chmod u+s /path/to/artisan
. (I have not tested).
Setting the setuid bit on artisan
could work, but is not recommended as it allows anyone to run artisan commands as www-data
.
This is less flexible but simple.
from docker-php.
Although this solution would work, this requires a lot of special "know-how" for Laravel developers. I don't think this would be easy enough for most users to have an easy development experience.
This is why I was thinking of adding a shell to www-data
. It's basically what Forge does on their servers.
Having a sudo policy was another thing I was thinking of, but that might add a lot of weight to the docker images.
I appreciate any other ideas/feedback if you have any!
from docker-php.
This is why I was thinking of adding a shell to
www-data
.
I'm confused, probably because of the plethora of new releases lol. I am deriving an image from php:beta-8.3-unit
and I can open an interactive terminal as www-data
, run one-off commands using docker exec -u www-data
etc. Doesn't that mean you've added "shell privileges"?
In any case, this capability is required for building a flexible PHP stack for more reasons than running artisan
. Scripts and permissions are often quite important when setting up a framework.
from docker-php.
@jaydrogers As you mentioned, the following command is not working ...
command: ["su", "www-data", "-c", "php artisan schedule:work"]
So, how i can run the horizon or task scheduler?
from docker-php.
A fix has been released π₯³
These changes are now live in our beta
images! Learn more about the release here:
Monitor this CI/CD job for the exact moment these changes will be live (takes about an hour to build):
from docker-php.
from docker-php.
@jaydrogers
Thanks, everything works like a charm in the development stage by setting UID and GID and changing the users.
But unfortunately i got this error in production when i don't want to make the same UID and GID and i want to run as www-data for security purposes:
My Dockerfile:
FROM serversideup/php:beta-8.3-fpm-nginx
USER root
ENV PHP_POST_MAX_SIZE=50M
ENV PHP_UPLOAD_MAX_FILE_SIZE=50M
RUN docker-php-serversideup-dep-install-debian "procps"
RUN install-php-extensions pgsql intl gd
USER www-data
from docker-php.
Related Issues (20)
- cURL error 28: Operation timed out after 15000 milliseconds with 0 bytes received HOT 1
- Check shell scripts HOT 4
- More typos HOT 4
- PRs fail because of the Nuxt content ENV not being set
- PRs fail because of Docker Logins are not set HOT 5
- I encountered issues with some vulnerabilities but couldn't find a way to update the dependencies. HOT 6
- Adding custom script fails to start HOT 2
- gRPC can't be found anymore! HOT 1
- Nginx Unit Docker Image Exposes Ports 80 and 443 alongside 8080 and 8443? HOT 1
- β οΈ Delayed release of v3.1.0 HOT 1
- mkdir() "/var/lib/nginx/body" failed (13: Permission denied) HOT 3
- Cannot start SSUPv3 docker image on Google CloudRun HOT 10
- Improve Horizon Support HOT 3
- nginx: [warn] the "listen ... http2" directive is deprecated, use the "http2" directive instead in /etc/nginx/site-opts.d/https.conf:2
- Apache container fails to restart HOT 5
- CrashLoop in K8s HOT 1
- Scheduler not working with S6 in new V3 images HOT 3
- Custom start up script not executing
- Running the image on Azure and other major cloud providers
- Nginx boots up and starts accepting connections when running a non default command.
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
π Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. πππ
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google β€οΈ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from docker-php.