From nobody Sat Sep 20 19:14:20 2025 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 4cTfFG5Crqz68Gmd for ; Sat, 20 Sep 2025 19:14:26 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from mail.protected-networks.net (mail.protected-networks.net [IPv6:2001:470:8d59:1::8]) (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 (2048 bits) client-digest SHA256) (Client CN "mail.protected-networks.net", Issuer "R13" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4cTfFG3H8Zz47tp; Sat, 20 Sep 2025 19:14:26 +0000 (UTC) (envelope-from imb@protected-networks.net) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d= protected-networks.net; h=content-transfer-encoding:content-type :content-type:in-reply-to:from:from:content-language:references :subject:subject:user-agent:mime-version:date:date:message-id; s=201508; t=1758395660; bh=f58U9dvKura8Ff7r2gPwTY4c7q824TFto1C4 d6m1UJw=; b=Biccj1bFfxeVCJMXL0/Tl0lngMiflgfM5BmtsBgMrX9zndNjbTqk MCujYwKbtJcDD3e42RHXKepGwHgtk+YIQg1wR3OljMWHWi7e4tB6rNiO+EZVqaeK RqJ1QLDBF7VjUmxlijMwt6MoxuFXDtbD0psB1uKs+y4FkLhr/5Oc7dw= Received: from [192.168.1.9] (d5540.auburn.protected-networks.net [192.168.1.9]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange x25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: imb@mail.protected-networks.net) by mail.protected-networks.net (Postfix) with ESMTPSA id 3BC4D5B5DD; Sat, 20 Sep 2025 15:14:20 -0400 (EDT) Message-ID: <9117a675-eca2-4384-8e9b-55bed2f4b501@protected-networks.net> Date: Sat, 20 Sep 2025 15:14:20 -0400 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 Thunderbird Subject: Re: Possible incompatible change with initgroups(3)? To: Olivier Certner Cc: freebsd-current@freebsd.org References: <20250920.080248.183796883139076827.yasu@FreeBSD.org> <3124332.hHqAuc6tWs@ravel> Content-Language: en-NZ From: Michael Butler In-Reply-To: <3124332.hHqAuc6tWs@ravel> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4cTfFG3H8Zz47tp On 9/20/25 04:54, Olivier Certner wrote: [ .. snip .. ] > There is no sign of out-of-memory anywhere here. It is true that this commit introduces a slight incompatibility, but we sometimes do that for bug fixes and in this case there should be only benefits (programs test for failure either with 'error != 0', which hasn't changed, or 'error == -1', which now will work correctly, preventing the program to continue without the expected credentials, or 'error < 0', same). > > The culprit is without doubt https://cgit.freebsd.org/src/commit/?id=9dc1ac8691966480, whose purpose is precisely to restore initgroups(3) compatibility that was lost after getgroups(2)/setgroups(2) semantics change. > > Why the symbol versioning mechanisms we are leveraging there don't work as intended isn't yet clear (to me at least), but this is clearly a bug as our intent is precisely that nobody has to recompile anything for things to continue working as before. FYI, we are pursuing that in https://reviews.freebsd.org/D52641. Another application affected by the initgroups behaviour tweak is net-mgmt/nrpe. It now refuses to start from an entry in rc.conf with the following log entries: nrpe: Starting up daemon nrpe: Warning: Possibly root user failed dropping privileges with initgroups() nrpe: Error: NRPE daemon cannot be run as user/group root! It will, however, run from inetd under the nagios user; thus avoiding the privilege change but incurring additional overhead of spawning a new process for each request. In this case, recompilation or tweaks to versioning have no benefit, Michael