From owner-freebsd-rc@freebsd.org Fri Jan 25 16:27:30 2019 Return-Path: Delivered-To: freebsd-rc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 61CB714BABF9 for ; Fri, 25 Jan 2019 16:27:30 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id D9EFE8B3E8 for ; Fri, 25 Jan 2019 16:27:29 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 3EB0F14BABF8; Fri, 25 Jan 2019 16:27:28 +0000 (UTC) Delivered-To: rc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 03E5114BABF7 for ; Fri, 25 Jan 2019 16:27:28 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8B7528B3A1 for ; Fri, 25 Jan 2019 16:27:27 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id F3E481EBEB for ; Fri, 25 Jan 2019 16:27:25 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x0PGRPAp055929 for ; Fri, 25 Jan 2019 16:27:25 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x0PGRPLE055928 for rc@FreeBSD.org; Fri, 25 Jan 2019 16:27:25 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f 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 Date: Fri, 25 Jan 2019 16:27:26 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: dteske@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: rodrigo@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2019 16:27:30 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D235185 --- Comment #15 from Devin Teske --- (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.=