From nobody Sat Feb 5 12:01:45 2022 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 0205E19B6827 for ; Sat, 5 Feb 2022 12:01:50 +0000 (UTC) (envelope-from se@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JrWGj6kjbz4RXg; Sat, 5 Feb 2022 12:01:49 +0000 (UTC) (envelope-from se@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1644062509; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=tJKhCD2/z9GOpAlrIL72te3Mr2gUUgoGoJbiB718Qbw=; b=DjG34CM9/7P5LVD8mm66qzGKRL1YAZsfvhSAG93zIbzNCEo55wXoj2dnkhkXVKnhtRytJG AA9bRTrbkBiE7urz3UYope0OT+SnFuUu2j1WtIaJqTYzG7TvZuUffbJtlCAaXTySbM4SYt +KmbQZ2f8mD/N4c2pu2czMFyFQZT32cEShpwYoFgO7xx2vKYcX/SM/afWRTzthTmwHsFfk 19dLLKSznCUx40QbkRssjZWAfcjPL6dggS4PWg6B8KK2NJNUgWlHf7NPKbxkLJGSRUtg31 Ev/fjIlExR6UQ63Tz/PVFjnxDxT+SHq9DND2ActWmNQeylOgtI7QjOs9tYucwA== Received: from [IPV6:2003:cd:5f0c:9800:ecf1:9d04:7fdb:712d] (p200300cd5f0c9800ecf19d047fdb712d.dip0.t-ipconnect.de [IPv6:2003:cd:5f0c:9800:ecf1:9d04:7fdb:712d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: se/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 7AEB3445E; Sat, 5 Feb 2022 12:01:49 +0000 (UTC) (envelope-from se@FreeBSD.org) Message-ID: <28a65581-bb25-9f60-5b15-ef4fd4a15ec9@FreeBSD.org> Date: Sat, 5 Feb 2022 13:01:45 +0100 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.5.1 Content-Language: en-US From: Stefan Esser To: FreeBSD CURRENT Subject: [REVIEW] Fix of sysctlbyname() accesses to user sub-tree variables Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1644062509; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=tJKhCD2/z9GOpAlrIL72te3Mr2gUUgoGoJbiB718Qbw=; b=h1WWoHhUrIL1x85fzHH3BoYHld0TWlaZ7W6ktNGqzlh/i2jfjVD1jumO6YP66By92xCCrW JKulxwJ9/ksOuZggsvEpejq+EDXZ3QwAxjtZpJ8SJpX8xJgV5x0fnXX4mhXAM0KcN4PyUV t3oMzqsFRS+RJNNu3a7e6fvvCr9VwB68qxsMlaeOAddlNzIDAummNjRTHZQptySEy6D9CJ O/px8Ro+FUsnJ+yBhfvweQLCk1mqHToTFaPFAGIrsniWBtA/ePwqe3RudjL09H4FCngROK C1CmaRyKhyF2wpJ28WK2MKTY0mkeSUcNdFhkPHte3PKzCl/4/tZkWjoVg+EjLQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1644062509; a=rsa-sha256; cv=none; b=CSWENLOaF7C3K1UnCcdHR8XfeMJucveMNqhMmskOslIW2MZ8Ie5mgKcZehCwrKwpa5zaTb ToF4sL46YKdmXlJTuPDGABODV6Fp3KRPIDR+bsx/2PcjgUqkCZ1b9EsdZVNRhAQ0MDN8Yu gmYExceOtmVNrn3UlhWmpcGDgSvflGq+0lwQYE+EJHV9nvf7oVk7l2HQopKQ3/Idlv/vUE 9H8cPlHYuitdWOzP1FZQaCH+vKq/wzv+JsyGQQzAQ8MgqK3fmn8qGEcXzWOanMkXpYWGyw +gO5NghbyNxhdja8qaep+he7UWS3csuJdJI2tbhwaSyQVTVg23acCrpLNZtHLA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N 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