[Bug 193701] New: [patch] rc.conf.d subdirectory support added in 271260 potentially sources /rc.conf.d/

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193701

            Bug ID: 193701
           Summary: [patch] rc.conf.d subdirectory support added in 271260
                    potentially sources /rc.conf.d/
           Product: Base System
           Version: 10.1-BETA1
          Hardware: Any
                OS: Any
            Status: Needs Triage
          Severity: Affects Many People
          Priority: ---
         Component: conf
          Assignee: freebsd-bugs at FreeBSD.org
          Reporter: code.jpe at gmail.com

Created attachment 147389
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=147389&action=edit
Proposed patch to etc/defaults/rc.conf and etc/rc.subr

Hi,

the newly added support for directories under rc.conf.d (MFC in 271260) has two
issues in my opinion.

1) it uses the shell variable $local_startup from /etc/defaults/rc.conf to
construct one of the paths to source files from. But the rc.conf loading
handler in rc.subr still has support to source /etc/rc.conf directly if
/etc/defaults/rc.conf does not exist. For this reason, $local_startup may be
empty. In this case, rc.subr will actually test "/rc.conf.d/$_name" for
sourcing.

2) we have the variable $rc_conf_files that defines the locations of rc.conf
files. This variable does not contain /usr/local/etc/rc.conf. Probably for this
reason, the patch introduces rc.conf.d directories relative to the value of the
$local_startup variable. Similarly, /etc/rc.conf.d is used without any relation
to the value of $rc_conf_files. Deriving a rc.conf.d location relative to the
path of startup scripts is incorrect in my opinion, because it introduced a
dependency between the paths that was previously not there.

This results in the following sourcing order, assuming /etc/defaults/rc.conf
exists and default values for $rc_conf_files:
1. /etc/defaults/rc.conf
2. /etc/rc.conf
3. /etc/rc.conf.local
4. /etc/rc.conf.d/$_name OR /etc/rc.conf.d/$_name/*
5. /usr/local/etc/rc.conf.d/$_name OR /usr/local/etc/rc.conf.d/$_name/*

I propose the attached patch, which introduces the following behavior. It
applies to 10.1-BETA1, I have not tested it against HEAD.

* extend /etc/defaults/rc.conf with the new variable $extra_rc_conf_files which
defaults to /usr/local/etc/rc.conf
* in /etc/rc.subr check if the variable $source_rc_confs_defined has been set,
as an indicator if the regular /etc/defaults/rc.conf, or the fallback direct
/etc/rc.conf sourcing happened
* if regular sourcing happened:
-- construct the rc.conf.d-directory paths $_d by appending .d to the values
from $rc_conf_files (with duplicate definition checks). Skip over rc.conf.local
-- check if $_d/$_name exists. Source it or $_d/$_name/* depending on if it is
a file or directory
-- for every entry in $extra_rc_conf_files, source it. then construct the $_d
directory from it and check that as well
* if the fallback sourcing happened
-- try sourcing from /etc/rc.conf.d and /usr/local/etc/rc.conf.d directly

This results in the following sourcing order, assuming the
/etc/defaults/rc.conf exists and the following values are set:
rc_conf_files="/etc/rc.conf /etc/rc.conf.local"
extra_rc_conf_files="/usr/local/etc/rc.conf /foo/bar/baz.conf"

1. /etc/defaults/rc.conf
2. /etc/rc.conf
3. /etc/rc.conf.local
4. /etc/rc.conf.d/$_name OR /etc/rc.conf.d/$_name/*
5. --skip /etc/rc.conf.local.d --
6. /usr/local/etc/rc.conf
7. /usr/local/etc/rc.conf.d/$_name OR /usr/local/etc/rc.conf.d/$_name/*
8. /foo/bar/baz.conf
9. /foo/bar/baz.conf.d/$_name OR /foo/bar/baz.conf.d/$_name/*

Since the directory paths are defined relative to the values of $rc_conf_files
and $extra_rc_conf_files, every entry in it automatically gets the "there may
be a .d directory for it" treatment as shown with the /foo/bar/baz.conf
example.

The $extra_rc_conf_files variable should really be called $local_rc_conf_files,
but this is confusing while /etc/rc.conf.local is still supported.

Folding /usr/local/etc/rc.conf into rc_conf_files with the current behavior of
sourcing the .d directories in rc.subr would result in /etc/rc.conf.d/$_name
overwriting /usr/local/etc/rc.conf which I consider a POLA violation.

Example of a FreeBSD 10.1-BETA1 system with the applied patch:

:~ # mkdir -p /etc/rc.conf.d/syslogd /usr/local/etc/rc.conf.d/syslogd
:~ # service syslogd rcvar
# syslogd
#
syslogd_enable="YES"
#   (default: "")

:~ # echo 'syslogd_enable="NO"' > /etc/rc.conf.d/syslogd/enable
:~ # service syslogd rcvar
# syslogd
#
syslogd_enable="NO"
#   (default: "")

:~ # echo 'syslogd_enable="YES"' > /usr/local/etc/rc.conf
:~ # service syslogd rcvar
# syslogd
#
syslogd_enable="YES"
#   (default: "")

:~ # echo 'syslogd_enable="NO"' > /usr/local/etc/rc.conf.d/syslogd/enable
:~ # service syslogd rcvar
# syslogd
#
syslogd_enable="NO"
#   (default: "")

Regards,
  Jörg

-- 
You are receiving this mail because:
You are the assignee for the bug.