From nobody Fri Aug 22 08:17:25 2025 X-Original-To: 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 4c7Y3g3SXQz65TYL for ; Fri, 22 Aug 2025 08:18:23 +0000 (UTC) (envelope-from Alexander@Leidinger.net) Received: from mailgate.Leidinger.net (bastille.leidinger.net [89.238.82.207]) (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 ECDSA (prime256v1) client-digest SHA256) (Client CN "mailgate.leidinger.net", Issuer "E5" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4c7Y3f5z8vz46ws; Fri, 22 Aug 2025 08:18:22 +0000 (UTC) (envelope-from Alexander@Leidinger.net) Authentication-Results: mx1.freebsd.org; none 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 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leidinger.net; s=outgoing-alex; t=1755850668; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=P8TW1EEATOHxlZzivl0D7nPEEcSt60FT8DtzmdRqeWU=; b=VuMtKpqo56KM10Y6pb/217eiRWU2ptMiTFSkgY9VXCKtFWtm1jHQqwkKMgb/QMsBUJOV/c hKOCWJJIj6UAqzBbDv7wmy+X8/pxzl8eFtOeUwrru9Uij+0EKXVwkYUbccE+UyjvVNLAuQ 55nIw04U7oIs6RIsueWHjAMPi88FVWXA/acwXHf/Kkvh/jHec8m7yRElXG+KVKXFcVJ37D 0+2fRbsexgjRj2lvTHbcXXkaT6sMilQzSafsg9NkmmbrnC12rRJAPX4zOfTiruvOtoSVXr vFNKMZkeFwocCT+WUDlECZOwjf/jY218zUgfMnA//RIL56TXdncm3Jjqe4p3ig== Date: Fri, 22 Aug 2025 10:17:25 +0200 From: Alexander Leidinger To: Xin LI Cc: Kyle Evans , Current Subject: Re: Big compat issue with a recent current (zfs + syscall) In-Reply-To: References: <567997960c33b7a437a8a812b7d65379@Leidinger.net> Message-ID: Organization: No organization, this is a private message. Content-Type: multipart/signed; protocol="application/pgp-signature"; boundary="=_098d3a5eaab850be0c69a0e8c1a01cc2"; micalg=pgp-sha256 X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:34240, ipnet:89.238.64.0/18, country:DE] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4c7Y3f5z8vz46ws This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --=_098d3a5eaab850be0c69a0e8c1a01cc2 Content-Type: multipart/alternative; boundary="=_f779c2029bd0f49f00bc5f6b186fe36f" --=_f779c2029bd0f49f00bc5f6b186fe36f Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8; format=flowed Am 2025-08-22 01:29, schrieb Xin LI: > On Thu, Aug 21, 2025 at 2:56 PM Kyle Evans wrote: > [...] > >> I don't think I'd expect it to help with zfs dataset stuff. > > There are also some recent ZFS changes, but I don't know (didn't have > read through all changes) if there are something related. > >>>> I had wondered the same, but the use of 'segfault' gave me pause; >>>> these would be SIGSYS rather than SIGSEGV, but that could just be a >>>> minor terminology dispute. >>> >>> Aug 20 10:35:32 Andromeda kernel: [566445] pid 52166 (auth), jid 50, >>> uid 143: exited on signal 6 (no core dump - sugid process denied by >>> ke >>> rn.sugid_coredump) >>> Aug 20 10:35:37 Andromeda kernel: [566450] pid 52172 (auth), jid 50, >>> uid 143: exited on signal 6 (no core dump - sugid process denied by >>> ke >>> rn.sugid_coredump) >>> Aug 20 10:35:44 Andromeda kernel: [566457] pid 52179 (auth), jid 50, >>> uid 143: exited on signal 6 (no core dump - sugid process denied by >>> ke >>> rn.sugid_coredump) >>> Aug 20 10:35:51 Andromeda kernel: [566463] pid 52185 (auth), jid 50, >>> uid 143: exited on signal 6 (no core dump - sugid process denied by >>> ke >>> rn.sugid_coredump) >>> Aug 20 10:35:56 Andromeda kernel: [566469] pid 52193 (auth), jid 50, >>> uid 143: exited on signal 6 (no core dump - sugid process denied by >>> ke >>> rn.sugid_coredump) >>> >> >> SIGABRT would seem to imply something like an assertion being tripped, >> which is a bit unusual. Might need to flip >> kern.sugid_coredump for a minute and see if you can gather some more >> context from a coredump. > > Well, yes (it's somewhat unusual) and no (I think it's expected > behavior here): It's not unusual for a program to explicitly abort() > when a setgroups() call failed, though: if I was the programmer who > wanted to drop privileges and failed, showing some error message and > abort() as soon as possible would be a reasonable choice (IMHO) because > I wouldn't have a lot of other remedies, so to me it sounded reasonable > here, especially when Alexander saw some missing system calls earlier. COMPAT_FREEBSD14 makes a huge difference. Seems you find the issue. We should change the UPDATING part and tell to use COMPAT_FREEBSD14 until all the 3rd party stuff is updated/recompiled. Bye, Alexander. -- http://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF --=_f779c2029bd0f49f00bc5f6b186fe36f Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

Am 2025-08-22 01:29, schrieb Xin LI:

=  

On Thu, Aug 21, 2025 at 2:56=E2=80= =AFPM Kyle Evans <kevans@freebsd.org> wrote:
[...]
I don't think I'd expect i= t to help with zfs dataset stuff.
 
There are also some recent ZFS changes, but I don't know (didn't have= read through all changes) if there are something related.
 
>> I had wondered th= e same, but the use of 'segfault' gave me pause; these would be SIGSYS rath= er than SIGSEGV, but that could just be a minor terminology dispute.
&= gt;
> Aug 20 10:35:32 Andromeda kernel: [566445] pid 52166 (auth),= jid 50, uid 143: exited on signal 6 (no core dump - sugid process denied b= y ke
> rn.sugid_coredump)
> Aug 20 10:35:37 Andromeda kerne= l: [566450] pid 52172 (auth), jid 50, uid 143: exited on signal 6 (no core = dump - sugid process denied by ke
> rn.sugid_coredump)
> Au= g 20 10:35:44 Andromeda kernel: [566457] pid 52179 (auth), jid 50, uid 143:= exited on signal 6 (no core dump - sugid process denied by ke
> rn= =2Esugid_coredump)
> Aug 20 10:35:51 Andromeda kernel: [566463] pid= 52185 (auth), jid 50, uid 143: exited on signal 6 (no core dump - sugid pr= ocess denied by ke
> rn.sugid_coredump)
> Aug 20 10:35:56 A= ndromeda kernel: [566469] pid 52193 (auth), jid 50, uid 143: exited on sign= al 6 (no core dump - sugid process denied by ke
> rn.sugid_coredump= )
>

SIGABRT would seem to imply something like an asser= tion being tripped, which is a bit unusual.  Might need to flip
k= ern.sugid_coredump for a minute and see if you can gather some more context= from a coredump.
 
= Well, yes (it's somewhat unusual) and no (I think it's expected behavior he= re):  It's not unusual for a program to explicitly abort() when a setg= roups() call failed, though: if I was the programmer who wanted to drop pri= vileges and failed, showing some error message and abort() as soon as possi= ble would be a reasonable choice (IMHO) because I wouldn't have a lot of ot= her remedies, so to me it sounded reasonable here, especially when Alexande= r saw some missing system calls earlier.

COMPAT_FREEBSD14 makes a huge difference. Seems you find the issue. We s= hould change the UPDATING part and tell to use COMPAT_FREEBSD14 until all t= he 3rd party stuff is updated/recompiled.

Bye,
Alexander.

--
= http://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF
http:/= /www.FreeBSD.org    n= etchild@FreeBSD.org  : PGP 0x8F31830F9F2772BF
--=_f779c2029bd0f49f00bc5f6b186fe36f-- --=_098d3a5eaab850be0c69a0e8c1a01cc2 Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc; size=833 Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEER9UlYXp1PSd08nWXEg2wmwP42IYFAmioJ6QACgkQEg2wmwP4 2IY//g//c+Z5TUCnMI2g+xGoLmsaBMLfHz8GLyRJqvCksCwLlntxB1gpq86OBUfV RUB8fNk7Y9Vrqb/kVqMCqYZz+vfSmq375Q4cjo2lYpg3AN5l6IX4PxWVP/++RAlw tkMmtGGTX4E4SmZZBmLNWTPVgc8GJ5Ic2SSWW/IbPJf0UokPZ6MXEECK8xBZ9p3w t+NE2V34dXwiVSPf+RiziuAkzWZjP7nFQ8P98jQfH6wqCBFQRItEx56YhPM92p+N Avb8gI/x2n0A/t0R8uTYzB2dRm9v8PFpzxUjUWQtKlmmBqOrbNLs4MOhG8c581Kf Z1iE/WfI8sj5dz6mSoldoX6mJx9otmy2IcgZtdpyEjb429/wGBUZDV2HPwRnXugK dVLC3nPdhb3n+3PGxn7IUqt/LHFegM3+c5sTIcoOPaSo8vRWR7jUUBF0vhmFI821 ogDjLfsR+aXMUsfMC+FGSrQl2Owh53miWlSE5gzbPc5BpsS5eGxyV5XdvutAe+Ie q18o3vuvYaU530jSFzaMaFoxty9YhdvQGRC1d878n28aqyyVcukwAwcj794N7lf6 HaiyPnjYpPUmJXHhOLrXSut3b1JL2wLnQrkLOjOry8HB2ZIYpw+a27V7Wa8DpXZ4 uGGtf8E5wGQwaGUoygR98k9txOjkCUf9IDNFza3NsreNsvlwKaA= =r23J -----END PGP SIGNATURE----- --=_098d3a5eaab850be0c69a0e8c1a01cc2--