This add No New Privs flag for start-stop-daemon and supervise-daemon
by adding --no-new-privs flag. As a result, the user set the No New
Privs flag for the program should run with.
see PR_SET_NO_NEW_PRIVS prctl(2)
This adds securebits flags for start-stop-daemon and supervise-daemon
by adding --secbits option. As a result, the user can specify
securebits the program should run with. see capabilities(7)
This adds capabilities for start-stop-daemon by adding --capabilities
option. As a result, the user can specify the inheritable, ambient and
bounding set by define capabilities in the service script.
This fixes#314.
This commit adds a new --oom-score-adj option to start-stop-daemon and
supervise-daemon, as well as an equivalent SSD_OOM_SCORE_ADJ environment
variable. If either of these are specified (with the command-line
option taking precedence), then the specified adjustment value is
written to /proc/self/oom_score_adj after forking but prior to exec'ing
the daemon (at the time when nice and ionice are applied).
Additionally, per a suggestion by Mike Frysinger, the suggested values
for the SSD_NICELEVEL, SSD_IONICELEVEL, and SSD_OOM_SCORE_ADJ variables
in the example config file are now given as zeros, which are the
kernel's default values of these process knobs for the init process at
boot. Note that uncommenting any of these zero-valued suggestions will
cause SSD/SD to set the corresponding process knob affirmatively to
zero, whereas leaving the variable unset (and the equivalent command-
line option unspecified) means SSD/SD will not change the corresponding
process knob from its inherited value.
See: https://github.com/OpenRC/openrc/pull/435#discussion_r688310672
This fixes#435.
start-stop-daemon and supervise-daemon parse usernames and group names
passed via the --user argument as numeric UID/GID if they start with a
number (e.g. user "4foo" will be treated as UID 4). This results in the
process that is being started to run under a totally unexpected user if
that UID exists.
Even though the result of the sscanf calls are tested for a result of
exactly 1, which means exactly one value was extracted, because sscanf's
format string only contains only one placeholder, it will never return
a value greater than 1, even if there are still characters left to be
parsed. This causes start-stop-daemon and supervise-daemon to assume
that usernames starting with a number are just that number. Adding a
second placeholder "%1s" to the format string, which matches a string of
length 1, makes sure that sscanf can distinguish between pure numbers
(in which case it will return 1) and strings either starting with a
number (in which case it will return 2) and any other string (in which
case it will return 0).
This fixes#379.
This fixes#380.
Starting program: /sbin/start-stop-daemon --start --exec i-dont-exist
Program received signal SIGSEGV, Segmentation fault.
0x0000555555559053 in main (argc=1, argv=0x7fffffffdc20)
at start-stop-daemon.c:631
631 *exec_file ? exec_file : exec);
This fixes#385.
In start-stop-daemon and rc-schedules, we were printing out a warning if
the nanosleep call was interrupted by a signal, but we did not treat
this as an error situation other than displaying the message, so there
is no need for the message.
If pidfile does not exist when we are stopping the daemon, assume it is
already stopped, and report success.
hostapd is an example of a daemon which removes its pidfile when it is
exiting. If this daemon terminates prematurely, that is, without s-s-d
involvement, then openrc fails to restart it, because s-s-d "stop"
command fails when pidfile is missing.
X-Gentoo-Bug: 646274
X-Gentoo-Bug-URL: https://bugs.gentoo.org/646274
In the past, OpenRC was a hybrid of a centralized and file-scope
license/copyright structure.
I followed the instructions from the Software Freedom Law Center [1] to
convert to a Centralized structure where possible, for easier future
maintenance.
[1] https://softwarefreedom.org/resources/2012/ManagingCopyrightInformation.html
The previous fix to --test (PR #34) prevented reading one too many
arguments when --exec -or --name was not specified, but created a
regression where the last argument would not print if either of those
arguments was specified. This corrects the issue.
Fixes#41.
Several calls to do_stop were forcing the test parameter to be true,
which was causing extra output to the terminal, such as:
* Would send signal 0 to pid xxxxx
This should only happen if the --test command line option was used.
The eerror calls in this function make it too verbose, so change them to
ewarnv() calls instead. This means that they will only print if the
--verbose option is used or EINFO_VERBOSE=yes is set in the environment.
Along the same lines as the quiet variable, this is controlled by an
environment variable for the einfo code, so we do not need a separate
boolean flag.
The suppression of output is controlled in the e* functions themselves,
so there is no need for a variable to test in start-stop-daemon.
X-Gentoo-Bug: 482396
X-Gentoo-Bug-URL: https://bugs.gentoo.org/show_bug.cgi?id=482396
The einfo() function tests for the EINFO_QUIET environment variable
directly, and this is the variable that is set by the --quiet flag, so
there was no reason for this test to exist.
