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

Stefan Esser se at freebsd.org
Mon Nov 2 22:51:15 UTC 2020


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

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

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

> But indeed I am not sure if this worth the effort of many people, for many
> hours.  If it puts too high burden on everybody, then it is not a good
> feature.  Otherwise, it is very convenient in some situations.

Up to now, not much effort has been spent on this issue. I have defined
_PATH_LOCALBASE in paths.h to make it available for the calendar program
to let it lookup port provided data files (and moving those to a port
will simplify the maintenance of these calendar files).

With _PATH_LOCALBASE available, it was sensible to replace literal uses
of /usr/local in the tree with references to this symbolic name (and
thus to easily build a base system for a different LOCALBASE value).

The addition of the user.localbase sysctl tool less than 20 lines of
code in 2 files (sys/kern_mib.c and lib/libc/gen/sysctl.c). This value
can now be used to make /etc/defaults/rc.conf adapt to a changed
LOCALBASE (just a few lines changed).

All in all less than 50 lines of code have been affected, but this
makes it much easier to build a system for a different (fixed)
LOCALBASE.

The getlocalbase() function proposed by Scott Long will allow to use
a user-configured LOCALBASE in programs that use this function instead
of a compiled in path. Another 20 lines of code, not complicated at all.

But the security implications of the use of a dynamic LOCALBASE can be
significant. And thus I do not think that we should put this function
into programs without a prior security assessment. And it would be a
major effort, which IMHO is not justified for most programs.

But this is not an argument against the steps that have been taken up
to now, with little effort and no weakening of security.

Best regards, STefan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 495 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/svn-src-head/attachments/20201102/40632cc2/attachment.sig>


More information about the svn-src-head mailing list