Date: Fri, 25 Jan 2019 16:27:26 +0000 From: bugzilla-noreply@freebsd.org To: rc@FreeBSD.org Subject: [Bug 235185] www/fcgiwrap: environment should be cleaned in /usr/local/etc/rc.d/fcgiwrap Message-ID: <bug-235185-20181-XEJfcWHzZ6@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-235185-20181@https.bugs.freebsd.org/bugzilla/> References: <bug-235185-20181@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D235185 --- Comment #15 from Devin Teske <dteske@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 t= o 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 wh= at 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=3DYES in rc.conf to enable a service, wha= t 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 r= un 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.). --=20 You are receiving this mail because: You are on the CC list for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-235185-20181-XEJfcWHzZ6>