[Bug 235185] www/fcgiwrap: environment should be cleaned in /usr/local/etc/rc.d/fcgiwrap

[bugzilla-noreply at freebsd.org]

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

--- Comment #15 from Devin Teske <dteske at FreeBSD.org> ---
(In reply to Kyle Evans from comment #1)
Hi Kyle,

Thanks for looping me in.

I've read through the responses and here is my take:

1. If the sanitization is in rc.d/fcgiwrap then you have to magically know that
it cleans its env and that would be why attempts to affect its runtime
environment will/would fail. Annoyance forecasted.

2. If the sanitization is in service but the rc.d/fcgiwrap script opts-in to a
feature provided by the init system, again the admin has to magically know that
it (fcgiwrap) cleans its env. Again, annoyance forecasted.

3. If perhaps instead the init system provided a mechanism for achieving what
the OP wants without hiding the setting inside the rc.d script itself, then
we'll avoid the above annoyances.

So here's the idea I arrive at:

a. As there is a generic *_enable=YES in rc.conf to enable a service, what if
we grew a *_noenv (name up for debate; not married to the name)

b. Any service can benefit from this

c. The admin, faced with rc.conf settings, ought to know if/when a service will
refuse any changes from, say, login.conf

This way we can retain the ability to modify login.conf (and subsequently run
cap_mkdb) to affect the environment of the user that a particular service
runs-as, without ever running into the situation where you find that a port
rc.d script version A did not sanitize but version B does (which would cause
fits of rage, I am sure). This puts the power in the hands of the sysadmin,
keeps it there, and centralizes it to places that sysadmins are known to
inhabit (rc.conf, login.conf, etc.).

-- 
You are receiving this mail because:
You are on the CC list for the bug.