These functions were never meant to be used outside of OpenRC, and they
were added when we thought we were going to do away with the automatic
detection of subsystems. Since the autodetection is not going away, we
can combine these functions into rc_sys.
The want dependency is similar to the use dependency. If a service
script, for example called service1, adds "want service2" to its depend
function, OpenRC will attempt to start service2, if it exists on the
system, when service1 is started.
However, service1 will start regardless of the status of
service2.
X-Gentoo-Bug: 406021
X-Gentoo-Bug-URL: https://bugs.gentoo.org/show_bug.cgi?id=406021
Rename the rc_conf_override function to describe its purpose better,
drop one conditional compile by making it available everywhere, and move
the call to it after the optional rc.conf.d directory is processed.
This makes it possible to override settings in rc.conf by adding a
directory @SYSCONFDIR@/rc.conf.d and putting files in this directory.
The files will be processed in lexical order, and the last setting in
these files will be used.
On Linux, the --netdev and --nonetdev switches were not working. They
were both returning false. After this change, they operate based on the
presence or abscence of the _netdev option in mount options.
All of the dependency type lists had the types_ prefix in their names;
this has been changed to deptypes_ to make them more self documenting.
Along the same lines, the setup_types function was renamed
setup_deptypes.
If a service has the same name as the runlevel it is in, openrc will
crash on changing to such runlevel. It goes in a recursive madness and
eventually gets a SEGV while in snprintf (don't know why).
This fixes two errors:
1. ls_dir stats files not with full path -> stat always returns != 0
2. ls_dir adds files to list if stat failed
This fixes#53.
X-Gentoo-Bug: 537304
X-Gentoo-Bug-URL: https://bugs.gentoo.org/show_bug.cgi?id=537304
If selinux is disabled, then stub methods will be provided instead of
calling the real methods. This removes some warnings about unused
parameters which used to be covered up with #ifdef HAVE_SELINUX.
Signed-off-by: Jason Zaman <jason@perfinion.com>
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.
This is another security fix. If you use chown() or chmod() on a
symbolic link, it affects the referenced file, not the symbolic link
itself.
X-Gentoo-Bug: 540006
X-Gentoo-Bug-URL: https://bugs.gentoo.org/show_bug.cgi?id=540006
Do not change permissions on the target if it is a file and has multiple
hard links. This is necessary because a hard link can be an attack
vector to gain privilege escalation.
X-Gentoo-Bug: 540006
X-Gentoo-Bug-URL: https://bugs.gentoo.org/show_bug.cgi?id=540006
runscript used to dlopen() runscript_selinux.so. This adds equivalent
functionality directly in to runscript instead. It authenticates with
either PAM or shadow and optionally has a dep on audit.
X-Gentoo-Bug: 517450
X-Gentoo-Bug-URL: https://bugs.gentoo.org/show_bug.cgi?id=517450
Check for __FreeBSD_kernel instead of __GLIBC__ in source files.
note from William Hubbs:
I was told this is a better check for GNU/kFreeBSD than checking the
C library the source is being compiled against.
GNU/kFreeBSD than checking which library we are using.
The stat structure was not being initialized correctly in do_check. This
was causing the owner adjustment to be skipped if the first path had the
correct owner.
Also, the "correcting owner" message should always be printed when the
owner is being changed.
X-Gentoo-Bug: 518042
X-Gentoo-Bug-URL: https://bugs.gentoo.org/show_bug.cgi?id=518042
Remove the recursive call in print_stacked_services which was causing an
infinite loop when using stacked runlevels.
I would like to thank Doug Freed and Jason Zaman for assisting with
tracking this down.
X-Gentoo-Bug: 514972
X-Gentoo-Bug-URL: https://bugs.gentoo.org/show_bug.cgi?id=514972
