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.
> > 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'. > > > 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. _______________________________________________ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"