[RFC][Change-Request] Create usefulness in rc.subr etc/rc.conf.d/*.conf namespace.

[Garrett Cooper]

On May 8, 2011, at 1:26 PM, Jason Hellenthal wrote:

> 
> Garrett,
> 
> On Sun, May 08, 2011 at 01:13:12PM -0700, Garrett Cooper wrote:
>> On May 8, 2011, at 12:13 PM, Jason Hellenthal wrote:
>> 
>>> 
>>> List, - Please reply-to freebsd-rc at freebsd.org
>>> 
>>> Recently I have been going over some changes in the configurations that 
>>> are possible with the rc subsystem and to my dismay I have found some 
>>> inconsistencies with in particular the way rc.conf.d directory is 
>>> processed and the arguments that are supplied to load_rc_config so I have 
>>> patched it up...
>>> 
>>> Let me explain:  As determined by rc.subr load_rc_config, config's from 
>>> rc.conf.d are loaded by the scripts $name as an argument to load_rc_config 
>>> and thus only the name being parsed is is available to be used in the 
>>> rc.conf.d directory. Why is this bad ? Its not! but it is inconvenient as 
>>> the user has no direct way to know that a variable used by nfsd is also 
>>> needed by mountd or the same for various other scripts in the rc.d 
>>> directory. At this time these config's are explained to be available for 
>>> the user to utilize by rc.conf(5) but yet without much knowledge of the 
>>> inner workings of the rc subsystem it would be quite the feat to do.
>>> 
>>> 
>>> The attachment[1] keeps this functionality the same while introducing a 
>>> more convenient approach for the user to modularize their configuration 
>>> however they see fit within a couple constraints that work very well. 
>>> 
>>> 
>>> What does it do ?: As stated above, current functionality is undisturbed 
>>> while allowing the user to create config's by any name they so desire as 
>>> long as it has an extension of ".conf", also introducing the ability to 
>>> turn a configuration file off by using chmod(1). You can turn nfsc1.conf
>>> off/on by simply chmod [-/+]x etc/rc.conf.d/nfs1.conf
>>> 
>>> 
>>> Why ? Simple. How many times have you been bitten by disabling something 
>>> in the rc.conf file and left to discover what you just disabled was also 
>>> used by another daemon but that daemon is now not starting ? This is a way 
>>> to virtualize your configuration allowing you to add multiple _enable= 
>>> lines to different configurations for different roles. For instance 
>>> rpcbind is used by both samba and nfs*. With this you can add 
>>> rpcbind_enable to both a configuration for samba and nfs and when you 
>>> disable one service you know that you have not disabled a dependent for 
>>> another.
>>> 
>>> 
>>> This is a small addition that fixes currently broken undesirable aspects 
>>> of the configuration system that deals with the rc.conf.d directory with a 
>>> SysV style init approach that is just as flexible. This should apply 
>>> cleanly to current and stable/8 & 8.2-RELEASE systems. Once more feedback 
>>> has been received Ill update the manual page with any suggestions 
>>> regenerate the patch to accommodate and file a PR.
>>> 
>>> 
>>> 1). http://patches.jhell.googlecode.com/hg/rc.subr_modular_conf.patch
>> 
>> 	Doing:
>> 
>> find /etc/rc.conf.d/ -type f -name '*.conf' -mindepth 1 -maxdepth 1 -perm +111 | while read _modular_conf; do
>> 	debug "Sourcing $_modular_conf"
>> 	. "$_modular_conf"
>> done
>> 
>> 	might be better. There's some more magic that could ultimately be done to make this more secure/robust using "-print0" | xargs, but it's up to you how you might want to go about solving that problem.
>> 	Also, I don't know if depending on a .conf file to be executable is necessarily the best course of action.
> 
> Yeah I see what you are getting at there and I came across thinking the 
> same thing. Fortunately /etc/rc.conf.d/*.conf is only one level deep 
> without using find(1).

Yes, but the above method used avoids simple E2BIG problems. It just doesn't properly deal with filenames that break on IFS, etc though (that's part of where I was leading, but I said "security" instead.

> As for the security sense if someone has a way to write to that directory 
> then most likely they are not going to be looking into placing anything in 
> that directory as theyll have rights to change anything under the rc sun! 
> plus anyting under most of the rest of the system.

Yes that's true. BTW, what about $local_startup?

> I do like the approach though. Thank you.

Thanks :).
-Garrett