Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 5 Feb 2022 13:01:45 +0100
From:      Stefan Esser <se@FreeBSD.org>
To:        FreeBSD CURRENT <freebsd-current@freebsd.org>
Subject:   [REVIEW] Fix of sysctlbyname() accesses to user sub-tree variables
Message-ID:  <28a65581-bb25-9f60-5b15-ef4fd4a15ec9@FreeBSD.org>

next in thread | raw e-mail | index | archive | help
I have created https://reviews.freebsd.org/D34171 for a patch
that restores the lost support for accesses to the user sub-tree
in sysctlbyname().

E.g. sysctlbyname("user.cs_path", ...) returns 0 to indicate no
error, but only an empty string, since the actual result string
is to be provided by the user-land code in the C library.

This functionality exists in sysctl(), which used to be called
by sysctlbyname(), but after an optimization that reduces the
number of system calls required, sysctl() is not longer called
and thus the empty result obtained from the kernel is returned.
(The system call is only used to check access rights, and a
non-zero return value would be returned to the caller, but the
actual value of the result string is not known to the kernel.)

One user land application affected by this issue is "whereis"
(just fixed in -CURRENT, MFC to -STABLE planned). But more out
of tree users of sysctlbyname() may exist that try to to access
user sub-tree variables, and thus this function should be fixed
to return the same results as sysctl() in all cases, as it did
before the optimization was implemented.

The code in the review special cases accesses to "user.*" and
uses sysctl() to fill in the actual value, but keeps the faster
direct system call for the variables actually maintained in the
kernel. It is simplified relative to the "old" implementation to
account for the implicit assumption that user.* names may only
have 2 elements in the OID array. (Codified in sysctl() and
would cause error returns if that assumption was violated.)

I'd appreciate a review and an approval of the change.

Regards, STefan



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?28a65581-bb25-9f60-5b15-ef4fd4a15ec9>