svn commit: r367280 - head/lib/libc/gen

[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.

> 
> 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.