Date: Sun, 8 May 2011 20:23:49 -0400 From: Jason Hellenthal <jhell@DataIX.net> To: Devin Teske <dteske@vicor.com> Cc: Garrett Cooper <yanegomi@gmail.com>, freebsd-rc@freebsd.org Subject: Re: [RFC][Change-Request] Create usefulness in rc.subr etc/rc.conf.d/*.conf namespace. Message-ID: <20110509002349.GI3527@DataIX.net> In-Reply-To: <D0B755B8-B222-49F4-BC6D-545231B7384A@vicor.com> References: <20110508191336.GC3527@DataIX.net> <C7EC90A2-936C-44E1-BC5E-E249399AF9AB@gmail.com> <5474DF9C-500A-4B51-948F-F56A66051476@vicor.com> <20110508215432.GG3527@DataIX.net> <F7C06E06-1913-4D29-B37F-7B07A0AE121A@vicor.com> <D0B755B8-B222-49F4-BC6D-545231B7384A@vicor.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--vSsTm1kUtxIHoa7M
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Devin,
On Sun, May 08, 2011 at 03:52:06PM -0700, Devin Teske wrote:
>=20
> I second Jilles all-builtin solution using `for' globbing (no forking ext=
ernal processes or sub-shells).
>=20
> Slight modification for brevity:
>=20
> 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
>=20
> Though I still think it ought to be:
>=20
> for _modular_conf in /etc/rc.conf.d/*.conf; do
> [ -f "$_modular_conf" ] || continue
> debug "Sourcing $_modular_conf"
> . "$_modular_conf"
> done
>=20
Keeping with the examples of the rest of the style of rc.subr and plenty=20
of other shell scripts here. This would be a distortion of the=20
functionality that the original loop is doing and should be avoided.
>=20
>=20
> >=20
> >=20
> >>=20
> >> I would suggest at least for those that doubt the SysV style way of=20
> >> enabling disabling scripts give it a try for a couple weeks then repor=
t=20
> >=20
> > GC and I aren't arguing that the SysV style is not helpful (if I read G=
C's post correctly). Just that these aren't wholly to-be considered SysV sy=
stem startup scripts, but instead "config files". If they had an interprete=
r she-bang (e.g., #!/bin/sh), program-flow, or other logic, I'd not disagre=
e with the checking of the executable bit. But since these files are by-des=
ign going to nearly always be KEY=3DVALUE pairs, I find it odd to think of =
them as anything other than just regular text files.
> >=20
In no way am I suggesting you are. That was a suggestion in general not=20
really pointed toward you but to everyone in general because workflow and=
=20
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 e=
qually foreign to me.
> >=20
> > 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 cu=
rrent interpreter. So in-reality they can contain any valid sh(1) syntax. T=
hough in-practice the only script of its kind that routinely contains more =
than just KEY=3DVALUE pairs is /etc/defaults/rc.conf (which defines the `so=
urce_rc_confs' function).
> >=20
> > However, I find it to be more common that engineers and technicians thi=
nk of rc.conf(5) as a flat text file, and thus will think of the `*.conf' f=
iles in /etc/rc.conf.d/ similarly, as text files. Thus it is my objection t=
hat the any permission other than the read-bit be checked.
> >=20
> >=20
> >> back. If feed back is strong discouraging it then we can probably come=
to=20
> >> common ground and find a way to work with both those who would like it=
and=20
> >> those who don't by default. I do have a pretty good idea what would wo=
rk=20
> >> to make it happen both ways but I really would like to advocate this i=
n=20
> >> place as it is now first.
> >=20
> > I think that I could live with the read-bit being a toggle. However, th=
e more experienced user may scratch his head, rationalizing that `root' sho=
uld 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=20
long been proven to be disasterous. There are probably some grey beards =20
out here that could contest to that. ;)
> >=20
> > Right now, I'm still thinking that the best solution is to:
> >=20
> > 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}
> >=20
These were things that were originally discussed with the way to handle=20
this type of situation which ultimately resulted in the way SysV init=20
scripts worked. There is alot more involved with mv(1) than just a=20
in-place chmod(1) and can become quite messy. People shouldnt be thinking=
=20
of the executable bit as something bad to turn on/off and shouldnt be=20
confused with a type of security issue either. It is actually a quite=20
common convention used to determine if something should happen to a file=20
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=20
like to get a greater amount of feedback as I also know of a way that it=20
could be turned on or off globally without too much adjustment as to not=20
inconveince the user. But this is a new way to look at configuration in=20
FreeBSD so the users have not been subjected to that yet and since we are=
=20
not in a hurry this can be dealt with properly for the masses.
--=20
Regards, (jhell)
Jason Hellenthal
--vSsTm1kUtxIHoa7M
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (FreeBSD)
Comment: http://bit.ly/0x89D8547E
iQEcBAEBAgAGBQJNxzQUAAoJEJBXh4mJ2FR+F+QIAJyN4q+KADqlML1x0dkWaQQ7
Yxcrzum/O26uUuV1dBohMT2f8enY1h2OGM9dNUCTyh3S2gQ8vuP8GWtaErEyKA1P
CX4uhbeVl3BiDF8MGEY0BSO0uFETWTHdpSmpHXYhp6jI81eibXT+tb9Rdlg6lBz7
Cv5FRy0KPzzh8sn+gNL8aTVW6Pipd5vwAPv4eqSAEeY6puJm+veAaoPyY7+CRkER
kLzgjDO+/wH7p65t7MZdROtyh8JWK986WpDuOwBy3YIqfyoABL8wmlwi1oCVmGsL
KJvYznq/zWb1PM6jorlnz4V5RfUhLRB23awVL7pc4sNq12zbQlNZ5qRY8c124sA=
=VJn4
-----END PGP SIGNATURE-----
--vSsTm1kUtxIHoa7M--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110509002349.GI3527>