Date: Mon, 26 Oct 2020 13:40:43 +0100 From: Stefan Esser <se@freebsd.org> To: Baptiste Daroussin <bapt@FreeBSD.org>, Scott Long <scottl@samsco.org> Cc: Warner Losh <imp@bsdimp.com>, Alex Kozlov <ak@freebsd.org>, src-committers <src-committers@freebsd.org>, svn-src-all <svn-src-all@freebsd.org>, svn-src-head <svn-src-head@freebsd.org> Subject: Re: svn commit: r366962 - in head: include usr.bin/calendar Message-ID: <51603415-2e4a-9525-72cf-7997880283f6@freebsd.org> In-Reply-To: <20201026080803.7h76fkrfwv4dhp4w@ivaldir.net> References: <202010230922.09N9MNZu040921@repo.freebsd.org> <20201024074840.GA26119@ravenloft.kiev.ua> <38d15142-1cb1-eb1f-215e-cee165743d99@freebsd.org> <20201025055633.GA52119@ravenloft.kiev.ua> <0140ae63-3044-9946-4047-c64331be0b50@freebsd.org> <20201026060038.GA78455@ravenloft.kiev.ua> <CANCZdfqHT=pYh9Roe2pvVHbTMHectjVwwv4HPU5jrUOORpKY8w@mail.gmail.com> <20201026075057.rbiwxbinzpkhh2tp@ivaldir.net> <8242C5E5-0F9E-4C17-BDBF-1926AF580325@samsco.org> <20201026080803.7h76fkrfwv4dhp4w@ivaldir.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Am 26.10.20 um 09:08 schrieb Baptiste Daroussin:
> On Mon, Oct 26, 2020 at 02:05:28AM -0600, Scott Long wrote:
>>
>>> On Oct 26, 2020, at 1:50 AM, Baptiste Daroussin <bapt@FreeBSD.org> wrote:
>>>
>>> On Mon, Oct 26, 2020 at 12:11:56AM -0600, Warner Losh wrote:
[...]
>>>> So, first off, it's already hard coded. Stefan's changes change the hard
>>>> coding from 'impossible to change' to 'changeable with a recompile' which
>>>> is an improvement. It might even wind up as a build variable (or not, doing
>>>> that has some really ugly, nasty dependencies).
>>>>
>>>> But even in ports-land, it's a compile time constant. Quite a large number
>>>> of ports will allow you to change it at compile / build time, but not
>>>> after. You have to rebuild if you want to change PREFIX...
>>>>
>>>> So I'm a bit puzzled what makes this the wrong approach?
>>>>
>>>
>>> I think what Alex revents to is the following:
>>>
>>> Some utilities in base base either have a configurable way to look for things in
>>> localbase (via configuration entries for instances):
>>> - syslog
>>> - periodic
>>> - rc
>>> - man
>>> Some have hardcoded LOCALBASE but only after looking first at the LOCALBASE env
>>> var:
>>> - usr.sbin/pkg
>>> - mailwrapper
>>>
>>> which means with a prebuilt base I can still rebuild all my packages with a
>>> different localbase and it will work with only a few configurations changes.
>>> which imho is a good target.
>>>
>>> The list of tools which hardcodes /usr/local
>>> - calendar
>>> - fortune
>>> - cron
>>> - bsnmp
>>> - nvmecontrol
>>> - cpucontrol (at least can be workaround via -d option)
>>>
>>>
>>
>> It would be pretty trivial to add a new libc function, something like getlocaldir.2,
>> that took care of searching the environment and the invoking a fallback to the
>> compile-time default from path.h. I’ll see if I can come up with something for
>> review before I fall asleep.
>
> Exactly what I was thinking about ;)
>
> could also be a simple static inline function somewhere (path.h?) if we don't
> want to "pollute" libc.
>
> I am fine with both.
I'm not opposed to having such a function, but please make sure we do
not open a security loop-hole.
If there was a mechanism that allows the effective LOCALBASE to be set
in a systctl variable, we could expect the valzue to be trustworthy.
If the LOCALBASE setting was provided in an environment variable, I'd
expect at the least, that the full path up to the root directory was
sanity checked (not writable by a non-priviledged account, for example).
Else I might be able to mislead a program that accesses a configuration
file in LOCALBASE that is under control of a privileged account to use
my version of the file.
A library function that provides the value of LOCALBASE should probably
recognize being invoked in a SUID program, but I guess we need quite a
number of extra safe-guards to avoid opening up gaping security holes.
Regards, STefan
PS: I consider work on a dynamic LOCALBASE orthogonal to the proposed
replacement of verbatim uses of /usr/local by _PATH_LOCALBASE.
Please let me know if you disagree and think that the proposed
change should not be applied for this reason.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?51603415-2e4a-9525-72cf-7997880283f6>