From owner-freebsd-rc@freebsd.org Mon Jan 28 09:31:46 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 9035314AD546 for ; Mon, 28 Jan 2019 09:31:46 +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 0CA5582A7B for ; Mon, 28 Jan 2019 09:31:46 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id C412114AD531; Mon, 28 Jan 2019 09:31:45 +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 B146514AD52E for ; Mon, 28 Jan 2019 09:31:45 +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 451C782A6A for ; Mon, 28 Jan 2019 09:31:45 +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 99BED2E70 for ; Mon, 28 Jan 2019 09:31:44 +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 x0S9ViAn017287 for ; Mon, 28 Jan 2019 09:31:44 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x0S9Vi1V017286 for rc@FreeBSD.org; Mon, 28 Jan 2019 09:31:44 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: Mon, 28 Jan 2019 09:31:44 +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: rodrigo@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: Mon, 28 Jan 2019 09:31:46 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D235185 --- Comment #35 from Rodrigo Osorio --- As the fcgiwrap port maintainer, this is my position: 1) If we can agree that starting services by invoking the scripts directly (just like not using sysrc to update rc.conf) isn't wrong, it comes with drawbacks and since this is not the 'recommended/standard' way to start a service, users who decide to go that way should live with -no offense-. 2) The use of env -i when calling the fcgiwrap script doesn't come at no co= st. The daemon will be started with en empty PATH variable. If this has no impact in many cases, I found a few ones who makes the script fail. The most problematic one is the 'which' command used by many cgi scri= pt to discover if a command exists, and recover its full path. Run in a 'sanitized' environment, 'which' returns nothing even for base tools like l= s.=20 Once again, I'm not against changing and improving tools but not at the cos= t of a massive web-server failure on D+1 with a immediate rollback. And I fully agree if someone wants to fix it at a higher level. --=20 You are receiving this mail because: You are on the CC list for the bug.=