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

[Jason Hellenthal]

Devin,

On Sun, May 08, 2011 at 03:52:06PM -0700, Devin Teske wrote:
> 
> I second Jilles all-builtin solution using `for' globbing (no forking external processes or sub-shells).
> 
> Slight modification for brevity:
> 
> 	for _modular_conf in /etc/rc.conf.d/*.conf; do
> 		[ -f "$_modular_conf" -a -x "$_modular_conf" ] || continue
> 		debug "Sourcing $_modular_conf"
> 		. "$_modular_conf"
> 	done
> 
> Though I still think it ought to be:
> 
> 	for _modular_conf in /etc/rc.conf.d/*.conf; do
> 		[ -f "$_modular_conf" ] || continue
> 		debug "Sourcing $_modular_conf"
> 		. "$_modular_conf"
> 	done
> 

Keeping with the examples of the rest of the style of rc.subr and plenty 
of other shell scripts here. This would be a distortion of the 
functionality that the original loop is doing and should be avoided.




> 
> 
> > 
> > 
> >> 
> >> I would suggest at least for those that doubt the SysV style way of 
> >> enabling disabling scripts give it a try for a couple weeks then report 
> > 
> > GC and I aren't arguing that the SysV style is not helpful (if I read GC's post correctly). Just that these aren't wholly to-be considered SysV system startup scripts, but instead "config files". If they had an interpreter she-bang (e.g., #!/bin/sh), program-flow, or other logic, I'd not disagree with the checking of the executable bit. But since these files are by-design going to nearly always be KEY=VALUE pairs, I find it odd to think of them as anything other than just regular text files.
> > 

In no way am I suggesting you are. That was a suggestion in general not 
really pointed toward you but to everyone in general because workflow and 
feel with an unbiased opinion yields results.

Sorry if I made that unclear, that is not always obvious as I am writing.

> > I think of the files in /etc/rc.conf.d/ as extensions of rc.conf(5) and the notion that permissions might possibly matter on rc.conf(5) would be equally foreign to me.
> > 
> > I'm aware that both rc.conf(5), the local variant, and newly-conceived rc.conf.d/*.conf are really in-truth just shell scripts sourced into the current interpreter. So in-reality they can contain any valid sh(1) syntax. Though in-practice the only script of its kind that routinely contains more than just KEY=VALUE pairs is /etc/defaults/rc.conf (which defines the `source_rc_confs' function).
> > 
> > However, I find it to be more common that engineers and technicians think of rc.conf(5) as a flat text file, and thus will think of the `*.conf' files in /etc/rc.conf.d/ similarly, as text files. Thus it is my objection that the any permission other than the read-bit be checked.
> > 
> > 
> >> back. If feed back is strong discouraging it then we can probably come to 
> >> common ground and find a way to work with both those who would like it and 
> >> those who don't by default. I do have a pretty good idea what would work 
> >> to make it happen both ways but I really would like to advocate this in 
> >> place as it is now first.
> > 
> > I think that I could live with the read-bit being a toggle. However, the more experienced user may scratch his head, rationalizing that `root' should be able to read anything (that is, unless something explicitly prevents it such as perhaps TrustedBSD MACs).

Read and write bits being toggled is too strong in environments and has 
long been proven to be disasterous. There are probably some grey beards  
out here that could contest to that. ;)

> > 
> > Right now, I'm still thinking that the best solution is to:
> > 
> > a. Put into packages: /etc/rc.conf.d/name.conf.sample
> > b. User enablement: mv /etc/rc.conf.d/name.conf{.sample,}
> > c. User disablement: mv /etc/rc.conf.d/name.conf{,.bak}
> > 

These were things that were originally discussed with the way to handle 
this type of situation which ultimately resulted in the way SysV init 
scripts worked. There is alot more involved with mv(1) than just a 
in-place chmod(1) and can become quite messy. People shouldnt be thinking 
of the executable bit as something bad to turn on/off and shouldnt be 
confused with a type of security issue either. It is actually a quite 
common convention used to determine if something should happen to a file 
and any other bit used directly either effects writing or reading of a file.

Again I am not against removing the -x but before that happens I would 
like to get a greater amount of feedback as I also know of a way that it 
could be turned on or off globally without too much adjustment as to not 
inconveince the user. But this is a new way to look at configuration in 
FreeBSD so the users have not been subjected to that yet and since we are 
not in a hurry this can be dealt with properly for the masses.



-- 

 Regards, (jhell)
 Jason Hellenthal

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 522 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-rc/attachments/20110509/1ef3ecb2/attachment.pgp