Linux start daemon as root

Security — Runing Daemon, program as root or user vs sudo su

«Big mistake» is overstating things. We prefer the phrase «Generally inadvisable», by which we mean that if you can run a process or service without needing root, you absolutely should, and when you can’t you should try to take utmost care to minimize the exposure risk.

2 Answers 2

The general idea is for a process to ask for (and have) the least amount of privilege it needs to do its job. Examples of this are web servers that bind to port 80 (which might need root) but then change to a non-privileged system user afterwards.

You may have noticed «might need root» not, «must have root». Traditionally, processes would have to start as root to bind to a port less than 1024 and would then change later. Now with capabilities if set up correctly you don’t need to do this. CAP_NET_BIND_SERVICE will let you bind to a port less than 1024 not as root.

This is another iteration of «doing the same with less». Why run as root with ALL the access that gives when you only need one aspect which is binding ports. Capabilities give you this granularity.

The difference between starting the daemon as root or as a different user and sudo as root is minor and generally will give the same results.

For editing, admin work etc most people prefer being a «standard» user and sudo for those tasks. Making it impossible to login as root closes one possible insecure door.

Software generally is installed as root. Why? Because if your webserver can modify its binaries or config files (why yes apache, I think your publically accessible directory should be /etc) is a bad idea.

Источник

How To Run A Command Or Script As Root On Startup / Boot Using systemd or A Cron Job

How to use systemd to run a command or script as root on boot

To use systemd to run a command or script as root when your computer boots, create a file (as root) called mycommand.service (replace mycommand with whatever you want to call it) in /etc/systemd/system/ .

We can use Nano command line text editor to open / create this file:

sudo nano /etc/systemd/system/mycommand.service

In this file, paste the following:

[Unit]
Description=your description
[Service]
ExecStart=/path/to/command/or/script
[Install]
WantedBy=multi-user.target

Here, change the Description value to describe what this does, and the ExecStart value to the command or path of the script you want to run as root on startup. Don’t add sudo at the beginning of the command or script, because it runs as root anyway.

Now save the file and exit Nano. In case you’re not familiar with Nano text editor, you can save the file by pressing Ctrl + o , then Enter . Exit by pressing Ctrl + x .

Next, you need to enable the systemd service to run on boot, using the following command:

sudo systemctl enable mycommand.service

Remember to replace mycommand.service with the actual filename you’ve used for this systemd service file. There’s no need to run the systemd service right now, since this is about running it on boot.

If you use this to run a script, make sure to make the script executable ( chmod +x /path/to/script ) or else it won’t run.

This is a very simple systemd unit file that runs only once. These can be a lot more complex, depending on what you need. For example, you could use a command that runs before ExecStart , have it start only after another unit becomes active, have the command run only after another service, e.g. the network service has been started ( After=network.target , while also declaring a dependency to this service using Wants= or Requires= ), and more. Check out the systemd.service and systemd.unit man pages for more details.

How to use a cron job to run a command or script as root on startup / boot

To use a cron job to run a command or script as root when the system boots, edit the root user crontab using:

And at the bottom of the file (it may also be empty), use the following:

@reboot /path/to/command/or/script

Now save the crontab and exit. If you’ve used Nano command line editor to edit it (should be default in most cases), you can save the file by pressing Ctrl + o , then Enter . Exit Nano by pressing Ctrl + x . Don’t add sudo before command or script, because it runs as root anyway, since it’s added to the root crontab.

In case you want to use a particular editor to edit the root crontab, run it like this: sudo EDITOR=editor crontab -e , e.g. for Vim: sudo EDITOR=vim crontab -e , or for Nano: sudo EDITOR=nano crontab -e .

• If you use this to run a script, make sure to make the script executable ( chmod +x /path/to/script ) or else it won’t run
• Use the full path to the command or script, or else it may fail to run (this depends on the Linux distribution you’re using, e.g. you don’t need to use the full path on Ubuntu 20.04 for example)
• If the script ran by cron also includes commands without the full path, you can avoid having to rewrite the script by adding this at the top of the crontab file: PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
• If you need to delay the start of the command / script, you can make use of the sleep command, e.g.: @reboot /usr/bin/sleep 60; /path/to/command/or/script to run the command or script 60 seconds after the system boots

Which to choose between systemd or a cron job to run a command or script as root on startup / boot, if you have a choice? When in doubt, pick systemd (if it’s available on your system) because it should be more reliable and easier to use.

For example, not every version of cron supports the @reboot option, or the command / script may only run when the system is rebooted, and not when it’s shut down (this didn’t happen for me on Ubuntu 20.04, Fedora 24, Manjaro Linux and Debian 10, but it may happen on some Linux distributions).

It’s also worth noting that @reboot configures a job to run once when the daemon is started. cron is not usually restarted, so this usually corresponds to the machine being booted. For example, Debian (and Debian-based Linux distributions) enforces this, making cron not re-run @reboot jobs when the cron service is restarted. On some Linux distributions, though, restarting the cron service may re-run the @reboot commands.

Also, on Fedora, cron is not installed by default (install it using sudo dnf install cronie ). On Manjaro, cron is installed by default, but not enabled by default (enable it using sudo systemctl enable —now cronie ).

Источник

Daemon — how to tell the start daemon to execute this daemon as different username than root?

I have this startup script, when i launch i have the execution done by username: root, instead of username: sun. How can i tell the start_daemon to execute it as username : sun not root?

$ ps aux | grep python root 950 0.1 0.2 171132 18936 ? S 05:35 0:00 /usr/bin/python /var/tmp/mp.py root@nson:/etc/rc0.d# cat K20mp #! /bin/sh PATH=/bin:/usr/bin:/sbin:/usr/sbin DAEMON=/var/tmp/mp.sh PIDFILE=/var/run/mp.pid test -x $DAEMON || exit 0 . /lib/lsb/init-functions case "$1" in start) log_daemon_msg "Starting mp" start_daemon -p $PIDFILE $DAEMON --user sun --chuid sun log_end_msg $? ;; stop) log_daemon_msg "Stopping mp" killproc -p $PIDFILE $DAEMON PID=`ps x |grep mp.py | head -1 | awk ''` kill -9 $PID log_end_msg $? ;; force-reload|restart) $0 stop $0 start ;; status) status_of_proc -p $PIDFILE $DAEMON atd && exit 0 || exit $? ;; *) echo "Usage: /etc/init.d/atd " exit 1 ;; esac exit 0 

Doesn’t the service start at all or does it start but run as root ? Does the user sun exist ( id sun )?

service starts fine. but the problem is it start as root. it needs to be started as username: sun ( # id -u sun 1000 )

1 Answer 1

—user and —chuid works but has to be used with start-stop-daemon.

Example: As root user if now execute: /etc/init.d/PythonGUI start it execute as username: sun

#! /bin/sh PATH=/sbin:/usr/sbin:/bin:/usr/bin DESC="Python GUI - Server" NAME=PythonGUI.sh DAEMON=/var/tmp/$NAME DAEMON_ARGS="--options args" PIDFILE=/var/run/$NAME.pid SCRIPTNAME=/etc/init.d/PythonGUI [ -x "$DAEMON" ] || exit 0 [ -r /etc/default/$NAME ] && . /etc/default/$NAME . /lib/init/vars.sh . /lib/lsb/init-functions do_start() < start-stop-daemon --start --quiet --user sun --pidfile $PIDFILE --chuid sun --exec $DAEMON --test >/dev/null \ || return 1 start-stop-daemon --start --quiet --user sun --pidfile $PIDFILE --chuid sun --exec $DAEMON -- \ $DAEMON_ARGS \ || return 2 > do_stop() < start-stop-daemon --stop --quiet --retry=TERM/30/KILL/5 --pidfile $PIDFILE --name $NAME RETVAL="$?" [ "$RETVAL" = 2 ] && return 2 start-stop-daemon --stop --quiet --oknodo --retry=0/30/KILL/5 --exec $DAEMON [ "$?" = 2 ] && return 2 rm -f $PIDFILE return "$RETVAL" >do_reload() < start-stop-daemon --stop --signal 1 --quiet --pidfile $PIDFILE --name $NAME return 0 >case "$1" in start) [ "$VERBOSE" != no ] && log_daemon_msg "Starting $DESC" "$NAME" do_start case "$?" in 0|1) [ "$VERBOSE" != no ] && log_end_msg 0 ;; 2) [ "$VERBOSE" != no ] && log_end_msg 1 ;; esac ;; stop) [ "$VERBOSE" != no ] && log_daemon_msg "Stopping $DESC" "$NAME" do_stop case "$?" in 0|1) [ "$VERBOSE" != no ] && log_end_msg 0 ;; 2) [ "$VERBOSE" != no ] && log_end_msg 1 ;; esac ;; status) status_of_proc "$DAEMON" "$NAME" && exit 0 || exit $? ;; restart|force-reload) log_daemon_msg "Restarting $DESC" "$NAME" do_stop case "$?" in 0|1) do_start case "$?" in 0) log_end_msg 0 ;; 1) log_end_msg 1 ;; # Old process is still running *) log_end_msg 1 ;; # Failed to start esac ;; *) log_end_msg 1 ;; esac ;; *) echo "Usage: $SCRIPTNAME " >&2 exit 3 ;; esac : 

update-rc.d apache2 start 20 2 3 4 . start 30 5 . stop 80 0 1 6 .

Runlevels are logical groups of tasks. Traditionally you have five run levels.

0 boot 1 single user 2 not used 3 multiuser 4 not used 5 gui 6 reboot 

Источник