Am 04.11.20 um 20:49 schrieb Konstantin Belousov:
On Mon, Nov 02, 2020 at 11:51:12PM +0100, Stefan Esser wrote:Am 02.11.20 um 23:10 schrieb Konstantin Belousov:On Mon, Nov 02, 2020 at 10:49:07PM +0100, Emmanuel Vadot wrote:I think that the first question we want to ask is : Do we want to support LOCALBASE being different than /usr/local 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. If they have some good argument, then we should proceed further.I would be delighted to be able to install _and use_ two independent set of packages from the same base system install. Without recursing to jails, X forwarding, etc.I understand the use case, and I agree this may be appropriate for a development system. But on a production system I'd never want to have a non-constant and not generally applied LOCALBASE, at least not on a system that gives a CLI to unprivileged users. Those could build their own copy of the LOCALBASE tree (e.g. sym-linking all sub-trees that are to be kept unmodified, replacing config files that policies that restrict the user).So how this makes attitude to the feature different ? For me, dev machine is my production box because what I do is development. And for user that need to run an old binary-only 32bit app which requires X libs, for instance, it also would be a production.
Maybe I'm using the term in a too strict sense, but it has been consistently used in this way in all the environments I have worked in during the last few decades: The term "production server" is generally applied to systems that are operated by e.g. an admin team (e.g. ITIL operations processes). You may consider your development work productive ;-), but that does not make your development system a production system as found e.g. in a server farm providing internal or public services. One difference between test&development vs. production systems is that development systems are generally operated under less tight security obligations. You are in full control of the system and could damage its integrity at will. It does not contain any data you are not authorized to access. The opposite is true of most "production systems", which need to be protected against attacks on confidentiality, integrity, and availability.
And if LOCALBASE is not compiled into binaries but somehow obtained at run-time, there are a number of attacks I can imagine (e.g. by LD_PRELOAD replace the sysctl() call in libc by your own version).If somebody can LD_PRELOAD their into your process, it makes no sense to talk about 'security'.
Yes, it takes some effort, but you could e.g. intercept fopen() calls and manipulate the file name argument. One of the suggested methods to make programs use a non-default LOCALBASE was by means of an environment variable, and that makes it trivial to have programs use an attacker-controlled value compare to a LD_PRELOAD attack, though. This is acceptable on a development system, but not on a production system, IMHO. I'm afraid that sysctl() could be intercepted, if it was used to determine a run-time value for LOCALBASE, but intercepting fopen() could accomplish the same result even for hard-coded paths ...
In fact I would like to use /usr/local and e.g /usr/local-i386 on amd64 machine. I am fine with me building both of them in my instance of poudriere.This is a use-case for architecture dependent path definitions (which I have used some 30 years ago on HP-UX which supported 68k and HP-PA on a single file system that way). Such a feature has been discussed in FreeBSD multiple times over the decades ...Ok, let replace /usr/local-i386 by /usr/local-11.4, if you so inclined.
Well, how about /compat/11.4-i386 then? The HP-UX implementation used e.g. /usr/bin/@hppa/ ... and when a file name lookup for /usr/bin/somefile did not find it in /usr/bin, it would try /usr/bin/@ARCH (with ARCH = hppa or 68k, IIRC). This is not exactly what you asked for, but our Linux emulation might already contain everything required to allow a 32 bit environment to exist on a 64 bit system. And by that I mean not the ability to execute 32 bin binaries that we already have, but e.g. to make path lookups by such binaries consider the compat prefix first. Ports built in the 32 bit environment should then find all their include files, libraries ... under the appropriate /compat sub-tree. That still leaves a few aspects undefined though, e.g. whether config files in /etc or $LOCALBASE/etc will be different in the "emulation", or shared with the base system. The same applies to /usr/share, which ought to be architecture independent. This could be an alternative layout to e.g. having 32 bit libraries in /usr/lib32 (with both supported for backwards compatibility). Regards, STefan
OpenPGP_signature
Description: OpenPGP digital signature