Re: pkg.c revision 367687 breaks pkg

Am 15.11.20 um 21:34 schrieb Kyle Evans:
> On Sun, Nov 15, 2020 at 2:05 PM Stefan Esser <se_at_freebsd.org> wrote:
>>
>> Am 15.11.20 um 20:41 schrieb Kyle Evans:
>>> This is a separate (valid) problem, but not directly related to
>>> Scott's work here. sysctlbyname now goes directly to the kernel with
>>> no chance for the user.* sysctls to intercept. That should
>>> independently be fixed to maintain the illusion that they're real
>>> sysctl's.
>>
>> user.localbase is a real sysctl, but with a default value returned
>> when sysctl(3) is used.
>>
> 
> Yup.
> 
>> The getlocalbase() function should not depend on this default value,
>> since it contains an identicl default value that can be returned if
>> sysctlbyname fails (or rather returns a zero length string in case
>> no other value has been written to the kernel).
>>
> 
> I don't care about this particular application, to be honest, but
> about the general problem. libc has a sizable chunk of code in
> sysctl(3) dealing with user.* sysctls, and sysctlbyname will never see
> it. This isn't documented in the manpage, and IMO it's really just an
> oversight; libc should still be able to provide the values as seen in
> ^/lib/libc/gen/sysctl.c whether you've invoked sysctl() or
> sysctlbyname(). At a glance, it looks like localbase is the only one
> that's also tunable, most of these don't really even need to take a
> trip to the kernel to read.

I have added user.localbase a few days back to -CURRENT.

Having it under "user" seemed a logical choice and I have preserved
the semantics of all the existing R/O cases.

The trip through the kernel has the effect, that the conditions for
access that are specified in kern_mib.c are checked, before the value
is then provided by libc.

I do consider this is a sensible approach, since it consolidates the
access checks / policy in the kernel, independently of detailed checks
in libc.

The values returned by libc are read-only system parameters, and they
could also be passed into the kernel, to be returned from there, but
this would not provide any useful added functionality.

Having getsysctlbyname() implement the same logic for accesses to the
user sysctl name-space seems sensible, and if nobody beats me, I'd be
willing to provide a patch for review.


Back to getlocalbase() and its supposed semantics:

Is it useful to have it return a NULL prefix (functionally equivalent
to returning "/")?

Having LOCALBASE/etc identical to /etc could lead to unexpected
behavior (e.g. to files being found twice if a program collects data
from both places), but might still be valid?

I'd consider an undefined return value from sysctl() to indicate that
the system default of (e.g.) "/usr/local" should be used, while a value
of "/" maps LOCALBASE files to be found relative to the root directory.

Regards, STefan