From owner-svn-src-head@freebsd.org Mon Nov 2 22:24:36 2020 Return-Path: Delivered-To: svn-src-head@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id BF9F945C9E5; Mon, 2 Nov 2020 22:24:36 +0000 (UTC) (envelope-from se@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4CQ6sc4dWCz45wr; Mon, 2 Nov 2020 22:24:36 +0000 (UTC) (envelope-from se@freebsd.org) Received: from Stefans-MBP-WLAN.fritz.box (p200300cd5f0bbc00143e0d922c7a134c.dip0.t-ipconnect.de [IPv6:2003:cd:5f0b:bc00:143e:d92:2c7a:134c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: se/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id E622E32F13; Mon, 2 Nov 2020 22:24:35 +0000 (UTC) (envelope-from se@freebsd.org) To: Emmanuel Vadot Cc: Oliver Pinter , src-committers , svn-src-all , svn-src-head@freebsd.org References: <202011021848.0A2Im7Kx098921@repo.freebsd.org> <338fdfbb-6fad-0e44-5df6-b5a1c38d3e4f@freebsd.org> <20201102224907.401c9200dffba42cab827b2d@bidouilliste.com> From: Stefan Esser Subject: Re: svn commit: r367280 - head/lib/libc/gen Message-ID: Date: Mon, 2 Nov 2020 23:24:34 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.16; rv:78.0) Gecko/20100101 Thunderbird/78.4.0 MIME-Version: 1.0 In-Reply-To: <20201102224907.401c9200dffba42cab827b2d@bidouilliste.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: de-DE Content-Transfer-Encoding: 8bit X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2020 22:24:36 -0000 Am 02.11.20 um 22:49 schrieb Emmanuel Vadot: > On Mon, 2 Nov 2020 22:41:38 +0100 > Stefan Esser wrote: > >> Am 02.11.20 um 20:20 schrieb Oliver Pinter:> On Monday, November 2, >> 2020, Stefan Eßer >> > wrote: >>> >>> Author: se >>> Date: Mon Nov  2 18:48:06 2020 >>> New Revision: 367280 >>> URL: https://svnweb.freebsd.org/changeset/base/367280 >>> >>> >>> Log: >>>   Re-arrange some of the code to separate writable user tree >>> variables from >>>   R/O variables. >>> >>>   While here fix some nearby style. No functional change intended. >>> >>>   MFC after:    1 month >>> >>> >>> Is there any phabricator reference for this / these commit(s) + reviewer >>> lists? >> >> The previous commit that has been refined in this one has been >> discussed in D27009. >> >> I had added the new R/W sysctl variable to a switch statement that >> contained one R/O string value, and excluded the OID from causing >> an error return when a new value had been passed. >> >> This was functionally OK, but I have decided to move handling of >> the new writable variable to before the check for a write attempt >> and thus need to test specifically for its OID. >> >> This sysctl variable is referenced in Scott Longs proposed >> getlocalbase() function (D27022), but also in the change to make >> it define defaults paths in /etc/defaults/rc.conf (D27014). >> >> I do not support to make LOCALBASE dynamic for a broad range of >> programs, since this could lead to severe security issues (e.g. >> when a program is restricted by policy settings LOCALBASE/etc and >> an user-defined LOCALBASE could be used to circumvent them. >> >> There are already programs that respect a LOCALBASE environment >> variable, e.g. the pkg program, to allow it to e.g. operate with >> a DESTDIR prefix other than "/". This is a program that could >> instead use getlocalbase(), IMHO. >> >> But for security reasons all files that determine policies and >> exist in LOCALBASE since they are not distributed as part of the >> base system, should be located in a secure way, and that is by >> referring to a compiled in trusted path, IMHO. >> >> Even if the sysctl variable "user.localbase" can only be written to >> by root, the use of getlocalbase() provided by a shared library could >> allow to perform a LD_PRELOAD attack (provide a getlocalbase() that >> leadsto a user provided policy file instead of the admin controlled >> one). >> >> Regards, STefan > > I think that the first question we want to ask is : Do we want to > support LOCALBASE being different than /usr/local The big majority of users will keep the default value, and I do not see a good reason for a change, except if there is a large installed base that traditionally uses another prefix (I have seen /vol/local and /opt, but also OS and architecture-specific prefixes, for example). > I honestly don't see any advantages of making it !=/usr/local/ and > before we start putting a lot of new/useless(for I guess 99% of our > user base) in the tree we should here why people are using /usr/pkg or > whatever weird location. No, why should we [assess] (assuming that word is to be implied in your sentence) why people want to be able to easily use a different prefix? That would be a waste of time, IMHO. I know that there are legitimate reasons to want a different prefix, and we had requests to make it easier to support it. We have literal uses of /usr/local in a lot of files in the FreeBSD base system (more than 1700) and this is not going to change. But it was easy to replace a number of such literal pathes in base system binaries, and we can make it easier for those that need a different prefix to get it consistently used. > If they have some good argument, then we should proceed further. You do not have to participate in this effort - there are so many other areas to work on (and I know you are very active in one). But please do not ask those that have started to reduce the use of literal /usr/local in the base system to justify this work. If you are happy with /usr/local, then you are not affected at all. And if you need to configure your system to use a different prefix, you are welcome to let us know which steps are still causing much effort and should be worked on to make it easier ... Do you have any reason to be against removal of literal /usr/local from the base system in favor of using a symbolic name for it? Regards, STefan