I'm running CentOS 5 and disabled the root login for security reasons.
Now, as root I could start and stop services like this:
httpd restart
mysqld stop
postfix start
but with the new user I set up I have to use /sbin/service process command
How can I set it up that the user also can access the process quickly?
Thanks!
add /etc/init.d/ to the path - e.g.
PATH=$PATH:/etc/init.d
And put it into the user's .profile
Related
Is there any way to change the owner of Tomcat catalina logs from root to my current (non-root) user in an Ubuntu server?
Tomcat needs to be started using a cronjob in root. I want to avoid having to type sudo every time I want to check logs.
Sure there is. Do not run tomcat as root to begin with. This way any problem/issue in your web facing application immediately has the highest privileges possible.
If the cron job runs as root: root can drop its privileges and start processes as another user account
I am having a problem keeping SSH running on the Windows Subsystem for Linux. It seems that if a shell is not open and running bash, all processes in the subsystem are killed. Is there a way to stop this?
I have tried to create a service using nssm but have not be able to get it working. Now I am attempting to start a shell and then just send it to the background but I haven't quite figured out how.
You have to keep at least one bash console open in order for background tasks to keep running: As soon as you close your last open bash console, WSL tears-down all running processes.
And, yes, we're working on improving this scenario in the future ;)
Update 2018-02-06
In recent Windows 10 Insider builds, we added the ability to keep daemons and services running in the background, even if you close all your Linux consoles!
One remaining limitation with this scenario is that you do have to manually start your services (e.g. $ sudo service ssh start in Ubuntu), though we are investigating how we might be able to allow you to configure which daemons/services auto-start when you login to your machine. Updates to follow.
To maintain WSL processes, I place this file in C:\Users\USERNAME\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\wsl.vbs
set ws=wscript.createobject("wscript.shell")
ws.run "C:\Windows\System32\bash.exe -c 'sudo /etc/rc.local'",0
In /etc/rc.local I kick off some services and finally "sleep" to keep the whole thing running:
/usr/sbin/sshd
/usr/sbin/cron
#block on this line to keep WSL running
sleep 365d
In /etc/sudoers.d I added a 'rc-local' file to allow the above commands without a sudo password prompt:
username * = (root) NOPASSWD: /etc/rc.local
username * = (root) NOPASSWD: /usr/sbin/cron
username * = (root) NOPASSWD: /usr/sbin/sshd
This worked well on 1607 but after the update to 1704 I can no longer connect to wsl via ssh.
Once you have cron running you can use 'sudo crontab -e -u username' to define cron jobs with #reboot to launch at login.
Just read through this thread earlier today and used it to get sshd running without having a wsl console open.
I am on Windows 10 Version 1803 and using Ubuntu 16.04.5 LTS in WSL.
I needed to make a few changes to get it working. Many thanks to google search and communities like this.
I modified /etc/rc.local as such:
mkdir /var/run/sshd
/usr/sbin/sshd
#/usr/sbin/cron
I needed to add the directory for sshd or I would get an error "Missing privilege separation directory /var/run/sshd
I commented out cron because I was getting similar errors and haven't had the time or need yet to fix it.
I also changed the sudoers entries a little bit in order to get them to work:
username ALL = ....
Hope this is useful to someone.
John Butler
I installed shiny server in a virtual machine (ubuntu server 14.04.4 in VirtualBox)
shiny-server --version
Shiny Server v1.4.2.786
Node.js v0.10.40
All in all the server runs nicely and starts apps as intended.
The only thing I'm missing and failing to achieve is that shiny server is running as an unprivileged user. I even completely set up a new VM and shiny server to make sure no trial config changes still take effect.
I changed my config to not contain any folders one needs root permissions for:
$ cat /etc/shiny-server/shiny-server.conf
# Instruct Shiny Server to run applications as the user "shiny"
run_as shiny;
# Define a server that listens on port 3838
server {
listen 3838;
# Define a location at the base URL
location / {
# Host the directory of Shiny Apps stored in this directory
# site_dir /srv/shiny-server;
site_dir /home/shiny/shiny_sitedir/apps;
# Log all Shiny output to files in this directory
# log_dir /var/log/shiny-server;
log_dir /home/shiny/shiny_sitedir/logs;
# When a user visits the base URL rather than a particular application,
# an index of the applications available in this directory will be shown.
directory_index on;
}
}
# privileges of shiny user
uid=1000(shiny) gid=1000(shiny) groups=1000(shiny),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),110(lpadmin),111(sambashare)
# owner of /etc/shiny-server
-rw-r--r-- 1 root root shiny-server.conf
# trying to start shiny server as user shiny without sudo
$ start shiny-server
start: Rejected send message, 1 matched rules; type="method_call", sender=":1.6" (uid=1000 pid=1134 comm="start shiny-server ") interface="com.ubuntu.Upstart0_6.Job" member="Start" error name="(unset)" requested_reply="0" destination="com.ubuntu.Upstart" (uid=0 pid=1 comm="/sbin/init ")
The server log tells me the same I see from the htop output that shiny server runs as root. (A side note: shiny server still uses /var/log/shiny-server.log instead of /home/shiny/shiny_sitedir/logs, which annoys me as well)
[...] [INFO] shiny-server - Shiny Server v1.4.2.786 (Node.js v0.10.40)
[...] [INFO] shiny-server - Using pidfile /var/run/shiny-server.pid
[...] [INFO] shiny-server - Using config file "/etc/shiny-server/shiny-server.conf"
[...] [WARN] shiny-server - Running as root unnecessarily is a security risk! You could be running more securely as non-root.
[...] [INFO] shiny-server - Starting listener on 0.0.0.0:3838
The shiny server documentation http://docs.rstudio.com/shiny-server/#running-shiny-server-with-root-privileges ships out a list of requirements to be fulfilled for non-root usage. Actually it defines states in which the shiny server needs to run as root:
If user_apps or user_dirs is enabled for any location. In order to host applications as various users, Shiny Server must have root privileges.
check. My shiny-server.conf neither uses user_apps nor user_dirs
If your configuration uses run_as to spawn applications as multiple different users.
check. run_as defines shiny as the only user
If you're running any server on a privileged port (a port in the range of 1-1024).
check. shiny server listens on port 3838
Although I think the installation fulfils the requirements shiny server still runs as root.
How do I force shiny server to run as shiny user or even an user not part of the sudoers group?
Does the shiny-server.conf need to locate anywhere else?
How would I make shiny-server aware of this new location then?
Do I need to change anything in /opt/shiny-server/config/ or any permissions on /etc/shiny-server/?
Edit after a comment by #warmoverflow I moved /etc/init/shiny-server.conf to ~/.init. Now, shiny server does not start automatically at boot up. But neither does start shiny-server succeed, because upstart is not aware of the ~/.init folder. From some forum posts it seems that dbus needs start, which it usually does by starting a graphical environment. As I'm running Ubuntu server this doesn't happen. Creating the two files mentioned in the upstart manual http://upstart.ubuntu.com/cookbook/#session-init doesn't help either, because the jobs fail to start.
Does anybody have a hint how to proceed or where I could find some information?
If your only goal is to ensure that shiny-server is running as non-root, and you are okay with start shiny-server using sudo (even if it's started with sudo, it can be running as a non-root user).
Edit /etc/init/shiny-server.conf, and
Add the following two lines at the beginning
setuid shiny
setgid shiny
Change the 3rd last line to
exec shiny-server --pidfile=/home/shiny/shiny-server.pid >> /home/shiny/shiny-server.log 2>&1
Note that Shiny has two default log file locations.
/var/log/shiny-server.log contains the logs for the server itself, and is defined in /etc/init/shiny-server.conf
/var/log/shiny-server/ is the folder that contains log files for your applications, and is defined in /etc/shiny-server/shiny-server.conf.
Once you made the changes above and also changed the run_as user, start shiny-server again with sudo start shiny-server, and you'll notice that shiny-server is in fact running as the non-root user, and the warning in the log file will be gone too.
I'm running Shiny Server v1.4.4.801 (Node.js v0.10.46). On this version shiny initialization is done via systemd.
To run shiny as a non-root one have to edit /etc/systemd/system/shiny-server.service file.
Add setuid shiny and setgid shiny commands to ExecStart like this:
ExecStart=/bin/bash -c 'setuid shiny; setgid shiny; /opt/shiny-server/bin/shiny-server --pidfile=/var/run/shiny-server.pid >> /var/log/shiny-server.log 2>&1'
Now, one can start shiny server by typing systemctl start shiny-server.service.
Type systemctl enable shiny-server.service to autostart shiny-server on reboot.
Here's another way to do this with systemd, if you're willing to run shiny server on a higher port number (> 5000).
Run systemctl edit shiny-server.service and add:
[Service]
User=shiny
Group=shiny
UMask=027
Then systemctl stop shiny-server.service and edit /etc/shiny-server/shiny-server.conf and change it to listen 8383;.
If you haven't already, do:
chown -R shiny:shiny /var/log/shiny-server* /etc/shiny-server
chmod -R u+rwX,g+rX,o-rwx /var/log/shiny-server* /etc/shiny-server
Start the service and it should be running as the service account user/group.
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 want to execute my scripts at boot time through systemd (OS is Fedora Core 16) from some non-root user (e.g. michael).
I don't need root privileges - I only want to run at boot time and at shutdown time some of my units in systemd. And I don't want to turn on a root user for this. I only want to use power of systemd syntax of units for starting and watching for my process (of course without root access). Is it possible?
I didn't find any help in the documentation. I only found in systemd(1) -> DIRECTORIES -> "User unit directories":
$ pkg-config systemd --variable=systemduserunitdir
/usr/lib/systemd/user
But the /usr/lib/systemd/user is:
drwxr-xr-x. 2 root root
I cannot imagine how I can use this directory as a non-root user...
This Arch Linux document may help.
systemd offers users the ability to run an instance of systemd to
manage their session and services. This allows users to start, stop,
enable, and disable units found within certain directories when
systemd is run by the user. This is convenient for daemons and other
services that are commonly run as a user other than root or a special
user, such as mpd.
They suggest starting a system --user instance via xinit, but I suppose you want to start the user services regardless of whether the user is logged in.
I would normally do that by adding an #reboot line to my crontab.
From Wikipedia:
#reboot can be useful if there is a need to start up a server or
daemon under a particular user, and the user does not have access to
configure init to start the program.
Maybe you can start systemd --user via #reboot!!!
Create a user systemd unit file for 'michael'.
Here's the magic to ensure users systemd process will kick off at boot instead of at login:
loginctl enable-linger michael
Full details