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 <b...@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.
_______________________________________________
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"
