I know the risks about running php-fpm as root.
However there are situations where one would need to do it, like appliances,
accessing operating system resources or even for testing purposes.
I have tried to change the user and group of php-fpm.d/www.conf to root
when I restart the php-fpm process it raise an error:
Starting php-fpm: [26-Jun-2014 00:39:07] ERROR: [pool www] please specify user and group other than root
[26-Jun-2014 00:39:07] ERROR: FPM initialization failed
[FAILED]
What should I do. Anyone help?
See:
# php-fpm --help
...
-R, --allow-to-run-as-root
Allow pool to run as root (disabled by default)
Just adding -R (like this ans. suggests) to your command may not work. It depends how your running the command to start php-fpm.
If you're using service php-fpm restart and it's using /etc/init.d instead of systemctl (see here), then you'll have to add -R to the DAEMON_ARGS variable located in the /etc/php/<phpversion>/fpm/php-fpm.conf script. (This variable is used in the do_start() function. See here).
If it's using systemctl then you'll have to edit the script used by systemctl which should be located in /lib/systemd/system/<phpversion>-fpm.service. Append -R to the ExcecStart variable. Then run systemctl daemon-reload and systemctl start php<version>-fpm (See here)
I used the following questions/answers/resources to help me compile this solution.
https://serverfault.com/a/189961
https://serverfault.com/q/788669
https://stackoverflow.com/a/52919706/9530790
https://serverfault.com/a/867334
https://www.geeksforgeeks.org/what-is-init-d-in-linux-service-management/
These 3 steps will fix the error.
Locate php-fpm.service. For me it's /usr/lib/systemd/system/php-fpm.service. If you're not sure where it is, type find / -name php-fpm.service.
Append -R to the ExecStart variable. Eg ExecStart=/usr/sbin/php-fpm --nodaemonize -R.
Restart php-fpm. If systemctl restart php-fpm throws an error, run systemctl daemon-reload.
To anyone else wondering how to make php run as root, you also need to modify /etc/php-fpm.d/www.conf or modify a copy of it. Both user and group need to be changed to root. If you've made a copy of www.conf, you'll also need to modify this line listen = /run/php-fpm/www.sock.
By default, php-fpm is shipped with a "www.conf" that contains, among others, the default www-data user configuration:
[www]
user = www-data
group = www-data
So, you need to create another file, loaded after www.conf, that will overwrite that default config. For example, create a file docker.conf in the same path as your php-fpm's Dockerfile and containing the following:
[www]
user = root
group = root
Then, in your Dockerfile, inject that file in your container with a name that will be loaded after the default www.conf:
COPY ./docker.conf /usr/local/etc/php-fpm.d/zzz-docker.conf
Update 2018
Running it within a container is a possible valid reason to run php-fpm as root. It can be done by passing the -R command line argument to it
Original answer:
However there are situations where one would need to do it, like appliances, accessing operating system resources
You never need to do it. That's it. If you are managing system resources, grant permissions for the php-fpm user to that resources rather than running the whole process as root. If your question would be more specific I could show how to do that in a certain situation.
Related
Hope you can help.
I am trying to enable audit logging in a docker container so if anybody kubectl exec to a docker container and runs any commands, then those commands get logged and we can view them in kubectl logs and capture with fluentd for example.
An option with adding the following line to /etc/profile of a container works for root but not for a non-root user as /proc/1/fd/1 is owned and writable by only root user and changing ownership or permissions, is not an option, unfortunately.
trap 'echo "$USER":"$BASH_COMMAND" >> /proc/1/fd/1' DEBUG
So far have tried the following:
A working option would be to run the container as a non-root, but unfortunately this is not an option
Option with just changing permissions/ownership doesn't change permissions/ownership
Also adding mesg y to /etc/profile to allow access to root's didn't work either as when doing su - non-root the permission gets denied (mesg: cannot open /dev/pts/2: Permission denied) - cannot change the permission
An option with adding a special file and trying to redirect the logs from there didn't work either, still the permission gets denied. For example:
mkfifo -m 666 /tmp/logpipe #create the special file
trap 'echo "$USER":"$BASH_COMMAND" <> /tmp/logpipe > /proc/1/fd/1' DEBUG # in /etc/profile
Changing to trap 'echo "$USER":"$BASH_COMMAND"' DEBUG won't work either as the logs need to go to /proc/1/fd/1 in case of docker
How would you enable command line audit logging in docker container or workaround the /proc/1/fd/1 permission issue for non-root in a container run as root user?
Any ideas highly appreciated.
Ah, came across my own question :D
So, Falco can be used as a HIDS (Host-based intrusion detection system), which will alert on any unusual activity based on rules defined in Flaco configuration. This can be deployed as a Deamonset (privileged) or directly on nodes.
I am trying to start avahi-daemon but it responds with and error
Failed to create runtime directory /opt/var/run/avahi-daemon/
That directory do exist.
Even if I delete this folder and start avahi again it creates it but still keeps saying that its a fail.
What am I doing wrong?
It's possible that such cases be linked with a lack of privileges.
=> use sudo
e.g.
sudo service dbus start
sudo service avahi-daemon start
Another issue could be the missing space of the file system. To check that do:
df -h /opt/var/run/
Result musn't be 100%.
I have a simple lua-nginx conf of this style
server {
server_name payment.mybackend.fr
payment.mybackend.fr;
set $rails_root /home/deploy/api/MAP;
set $env 'cloud';
location ~ /(paypal|paybox_system) {
content_by_lua_file $rails_root/lib/nginx-redis-payment/$1.lua;
}
}
When I run nginx without sudo, with my current user, the lua script is never called and so the payment is not validated.
When I run it with sudo, it works perfectly.
How can I make nginx don't use root privileges to execute my lua scripts?
Provided your nginx itself runs without sudo, just not executing the scripts in question...
This is likely related to the lua scripts in question, and have not much to do with nginx.
I would troubleshoot as follows:
Make sure nginx itself runs without sudo. You could use pkill nginx and/or pkill -KILL nginx, followed by pgrep nginx to make sure that no nginx instances are presently running. Then execute nginx without root to make sure it starts up and keeps on running.
Try to execute the script under the same user as the one you use to run nginx. If this fails, provide us with the errors and any possible logs generated, as well as id and ls -la of the files and directories in question.
Look further into any possible logs that nginx as well as the scripts generate when they fail.
I don't have permission to post a comment on your answer, so my apologies if this answer should belong in the comment section instead as answer.
I experienced something similar a while ago, and I came up with an idea: https://stackoverflow.com/questions/32593747/idea-for-reload-restart-apache-from-php-script-without-running-as-root
The idea is the same: you don't want to run Nginx as root for security reasons, but you really want to execute some pre defined commands as root. With a non root script (let's say you put a php script at your location "/(paypal|paybox_system) ") so it can write to a watch folder, the daemon (which runs as root) then gets a signal and executes a root commando (for example running your lua script as sudo).
varnishlog is returning:
_.vsm: No such file or directory
Has anyone else seen this before?
It looks like varnishlog is not pointing to the correct directory, or has not access to it.
Please check the command line options of varnishd. If the deamon run with -n <instancename> argument, you have to add it to varnishlog as well.
The second thing, is to see the permissions of varnish directory.
In order to see the current directory used, you must log into root and run the command below :
$ lsof -p <PID of varnishd> | grep vsm
Once revealed, you just had to be sure the full path has read permission for your user.
In Varnish 4.1 the root cause can be due to incorrect rights for reading _.vsm file. For example:
# service varnishncsa start
* Starting HTTP accelerator log deamon [fail]
Can't open log - retrying for 5 seconds
Can't open VSM file (Cannot open /var/lib/varnish/dev-me/_.vsm: Permission denied
Varnishncsa works from varnishlog user. But /var/lib/varnish/dev-me/_.vsm can be readable from varnish group or root user only:
# ls -l /var/lib/varnish/dev-me/_.vsm
-rw-r----- 1 root varnish 84934656 Apr 15 05:58 /var/lib/varnish/dev-me/_.vsm
So you can fix this problem in the following way:
# usermod -a -G varnish varnishlog
# id varnishlog
uid=110(varnishlog) gid=116(varnishlog) groups=116(varnishlog),115(varnish)
And now you can start varnishncsa.
In our case the hostname of the server was changed.
If you do not specify an instance name, varnish uses the hostname. It was looking for a directory holding the shared memory logging configuration with the new hostname, but the instance was still running from the directory with the old hostname.
Restarting varnish solved the problem.
I just had the same error message while trying to issue varnishadm commands. Turned out that I renamed my machine without stopping varnish. There was some directory in /var/varnish/ corresponding to the machine name that varnish needed access to. "sudo service varnish restart" fixed this for me.
What I've done so far according to these instructions is unziped and moved jboss into my /usr/local/ directory. Then I put the jboss_init_redhat.sh script in /etc/init.d/ as jboss and edited the script to meet my configurations. I then run /etc/init.d/jboss start and all it says is
JBOSS_CMD_START = cd /usr/local/jboss-4.2.3.GA//bin; /usr/local/jboss-4.2.3.GA//bin/run.sh -c default -b 0.0.0.0
and then nothing happens. Also if I go into /usr/local/jboss-4.2.3.GA/bin and run run.sh it starts the server but when I go to the vm's IP:8080 in my browser I still get nothing. Any help would be appreciated also I don't know much about doing this so excuse my inexperience.
Init scripts should be owned and started by root.
The init script you use uses su (better would be to runuser) to change to the jboss user.
The jboss user itself does not have permission to do that.
The jboss user also does not have permission to write to /var/run etc.
So run sudo /etc/init.d/jboss start (you need to set up sudo first to allow this) or change to the root account and execute /etc/init.d/jboss start.
If it still fails check the logs at /usr/local/jboss-4.2.3.GA/server/default/log.
Hope this helps.