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).
Related
I read this article about why you shouldn't run containerized applications as root user,
and I'd like someone to confirm my understanding:
Article brief
The article is basically saying that just as you won't run binaries on your machine
as root, but rather as a least-privileged-required user, you won't run containerized applications as root either.
The recommendation of the author is to create a user with a known uid in the Dockerfile
and run the process as that user.
The start of the dockerfile should look like
this:
FROM <base image>
RUN groupadd -g 999 appuser && \
useradd -r -u 999 -g appuser appuser
<br>USER appuser
... <rest of Dockerfile> ..
Validating my understanding, and some questions:
1. Why bother?
Ok, I understand that it's not good to run a container process as root,
just like it's not good to run any process as root.
That's why we should create a user in the Dockerfile and run the application process as that user.
But, if it's possible to run:
~$ docker run -u 0 some_docker_image
then why bother adding a user to my Dockerfile and switch to that user?
The question boils down to the question: What are we "afraid" of? What is the threat?
If the answer is that we're afraid of some untrusted user connected to the system (who is not a sudoer),
then this user can't even run docker containers, unless he is a member of the "docker" group,
in which case - again - he could run the container with -u 0?
So I guess that we're not concerned about the user. We're concerned about the binary itself.
In that case, two possible options exist:
a. The binary is of our creation. In that case: why are we concerned?
b. The binary is of someone else's creation. In that case i can understand why we would like to
switch user.
Am I missing something?
2. Why "Known uid"?
Why is that important to specify the uid of the newly created user, and not just name it something?
3. Why in the start of the Dockerfile?
Is it important to create+switch to the new user in the beginning of the Dockerfile?
Seemingly, this is an approach that's hard to implement, since usually during the docker build process
you need to run a lot of tasks that require root privileges, such as apt-get install etc.
4. What about adding a user and adding it to sudoers?
I have a case in which I need to create a docker image, which when the container runs,
it'll run a ssh server. In order to run the ssh server, you need root privileges.
Is there a point creating a user, adding it to sudoers, and then run the ssh server as root?
Running as root in Docker is dangerous for most of the same reasons as running as root directly on the host. The container has limited Linux privileges so there are some things it can't do (reconfigure the network, reboot the host), but it can do things like overwrite the application code inside the container.
Nobody's code is absolutely perfect, so one of the big reasons to run as non-root is to minimize the damage possible when a mistake does happen.
It doesn't matter what the user ID is, just that it's not 0. There's an argument to make it different from any uid the host might be using, but since your image could run on any host, it's just a guess.
You should create the user at the start of the Dockerfile, since that setup will change infrequently and Docker layer caching can skip it. But, you should use the USER directive and switch to the user at the end of the Dockerfile, after COPYing code in and RUNning the build. Do not RUN chown ... to make the non-root user own the code: you want most files to be owned by root, so that the non-root user can't overwrite them.
(In a compiled language, with a multi-stage build, you can consider the Dockerfile equivalent of the ./configure; make; sudo make install sequence, switching to a non-privileged user to do the build. I haven't seen this pattern in many Dockerfiles but I'd recognize it if I saw it.)
Do not add a user to /etc/sudoers. There are a couple of good reasons for this. The most basic one is that a container only runs a single process, and as already discussed we probably don't want it to be root. You can either configure it with no password (in which case you might as well be root) or hard-code a password in plain text in your Dockerfile (also a bad idea). You also usually don't want to run sudo inside a script (its behaviors of putting up random password prompts and hiding environment variables can cause trouble), and so correspondingly don't want to RUN sudo ... in a Dockerfile.
If you need to break into a container to debug it, you can always docker exec -u root ... to get a root shell there.
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.
I can't add /usr/local/bin to the apache users PATH variable. The user doesn't have a .profile, I can't su to the user, I can't export to the PATH from php using exec and adding
SetEnv PATH /usr/local/bin
To either the http.conf or the .htaccess file doesn't make a difference. I can't find the envvars file to change that but I suspect there's some other problem.
I have restarted apache, and indeed my server.
Ended up following what Alfe suggested in his answer, except rather than in the /etc/init.d/httpd file (which could be overwritten easily on update) I added to /etc/sysconfig/httpd:
export PATH=${PATH:+$PATH:}/usr/local/bin
Have a look at the /etc/passwd to see which login shell the apache user has (on EC2 Ubuntu instances it should be /bin/sh which is a link to /bin/dash). Then have a look at the man page of that shell and find out which configuration files are read upon login. (For /bin/dash that would be .login in the user's home directory.) In those you should be able to extend your $PATH as you like.
EDIT:
Since you seem to have no login shell for that user: Have a look at the /etc/init.d/* scripts which start the system services. Apache will be one of them. They are started as root and may change the current user (e. g. to the apache user). In there you might be able to adjust the PATH as you like it.
Patching those scripts, however, is not considered typical configuration. Updates might overwrite what ever you patch there.
I am currently writing an admin page for my webserver, to make it easier on myself to create new apache domains from my browser. Everything is pretty much working as I want it to, except for one thing.
To elaborate: I have a cron job on my server running a bash script as root that checks a file containing a list of domain names that I want to be created. If the file contains a domain name, it automatically creates a new virtual host for this domain, edits my hosts file, and restarts the server. This all works perfectly, however what I would like for the script to do, is that it activates the domain that it automatically creates before it restarts the server. I tried doing this using apache 2's a2ensite command, however the script returns an error saying the command is not found.
Is there a way to call this command from a bash script, or is there an alternative to this command that I can call?
Any help would be greatly appreciated.
$ which a2ensite
/usr/sbin/a2ensite
Usually, cron has a quite restrictive $PATH, not including /usr/sbin or /sbin, which are system binaries (for use by root). It's always a good idea to use fully qualified path names. So either call /usr/bin/a2ensite in your script, or define a variable:
A2ENSITE=/usr/sbin/a2ensite
...
${A2ENSITE} new-domain.com
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.