From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7B21A39AD44; Tue, 12 May 2026 13:06:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778591182; cv=none; b=jHoCUc1z5wEeLu63AQ8WuBStBxdhbW0QgGBpWWCF3y+8uIm8vMj9iXya8J6et8UUx+1+mZtXKVInKdriZkd8S8e8YQ3rPYU5Zsrw+TCxs2uvjBRkW9AAC2L4A/dMLNBP46s9dteL8/ofuMuuqP1dYLv+XuTjQJOaNzFi5mDiKcI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778591182; c=relaxed/simple; bh=UFLh1HQgMVqyhIdcFfusQ2fCIb61H7oDcv3Fks5hcaI=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=KCIMWUmOyU+RTpyYqIVc5j6pHq7NXeq3SxlIb6Degf1CK7hbqS9jPPQtZp8dPQm3TDSMdchLdC3EeVaLU4hYfGWiTdrpQ8b41+XRj88FbHi0FyRKx/nS5nTEVXAo4jorn+kZdQwlzvPp4CBljWqjPz8X/G7kENGjJyybETuL67s= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=OigBHdyY; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="OigBHdyY" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7FCF6C2BCB0; Tue, 12 May 2026 13:06:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1778591182; bh=UFLh1HQgMVqyhIdcFfusQ2fCIb61H7oDcv3Fks5hcaI=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=OigBHdyYCbSkyyYJz6QrJH3KYMSIvtlAOUcjWa3CC9hvJooqA61fezXX9Re/DWLzX yZ00J0vFIkefV1t6g5WAnvIOtzF/msDuR8WjVl3nUS4C/jYUodzgjbOfv+BN/7tIJd vaQXyjVeRsT4rOGE83hIFlAwBbBD605lLXU2wKZf+pXQTJcSnd/DCKVyVC4v0SDatn iVt09xOZg9xi2qlbj5oPwxYvo1isXtXHHM8v7+XUMl9Xz977t/iG5Q6CAlbneLJrvb UNkM5XnRsW0s1TtnGsm7ScxI175pctMoM/7CZy2r6Sl49h/MiTxR5L50tdLZSv6ROF d8S2jMfkvw+uA== Date: Tue, 12 May 2026 15:06:14 +0200 From: Christian Brauner To: Kuniyuki Iwashima Cc: Jori Koolstra , Alexander Viro , Jan Kara , Eric Dumazet , Paolo Abeni , Willem de Bruijn , "David S . Miller" , Jakub Kicinski , Jens Axboe , Kees Cook , Simon Horman , Andy Lutomirski , Will Drewry , Jeff Layton , Oleg Nesterov , Andrei Vagin , Pavel Tikhomirov , Mateusz Guzik , Joel Granados , Charlie Mirabile , Aleksa Sarai , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, netdev@vger.kernel.org, io-uring@vger.kernel.org Subject: Re: [RFC PATCH 1/2] net: af_unix: Useful handling of LSM denials on SCM_RIGHTS Message-ID: <20260512-sparflamme-themen-4f3f10225b2a@brauner> References: <20260428175125.2705296-1-jkoolstra@xs4all.nl> <20260428175125.2705296-2-jkoolstra@xs4all.nl> Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Wed, Apr 29, 2026 at 07:04:25PM -0700, Kuniyuki Iwashima wrote: > On Tue, Apr 28, 2026 at 10:51 AM Jori Koolstra wrote: > > > > Right now if some LSM such as Smack denies an AF_UNIX socket peer to > > receive an SCM_RIGHTS fd the SCM_RIGHTS fd array will be cut short at > > that point, and MSG_CTRUNC is set on return of recvmsg(). This is > > highly problematic behaviour, because it leaves the receiver > > wondering what happened. As per man page MSG_CTRUNC is supposed to > > indicate that the control buffer was sized too short, but suddenly > > a permission error might result in the exact same flag being set. > > Moreover, the receiver has no chance to determine how many fds got > > originally sent and how many were suppressed.[1] > > > > Add two MSG_* flags: > > Since we only have 5 bits remaining for future extension, > we need to consider the use case a bit more carefully. > > > > - MSG_RIGHTS_DENIAL is set whenever any file is rejected by the LSM > > during recvmsg() of SCM_RIGHTS fds. > > Is this really needed ? > > Even if the fd array is truncated, the application will traverse > the array anyway since it has some fds already installed (to > clean up in case of MSG_CTRUNC ?). The socket option suggested later: Wouldn't it be simpler to just add a socket that instructs the scm layer to send all fds that were denied with a -EPERM sentinel. Then systemd can: * detect all fds that were denied simply by seeing they were -EPERM * keep the count in tact and - see below - get rid of the blatant layering violation in here... > Then, it will find the -EPERM entry. I assume we're talking about the same thing. All the complicated rest should be dropped. There's a bunch of nonsense in that uapi entry - quite a few items are merely drafts. > > -int receive_fd(struct file *file, int __user *ufd, unsigned int o_flags) > > +int receive_fd_msg(struct file *file, int __user *ufd, unsigned int o_flags, > > + unsigned int *msg_flags) > > { > > int error; > > > > error = security_file_receive(file); > > - if (error) > > + if (error) { > > + if (msg_flags) > > + *msg_flags |= MSG_RIGHTS_DENIAL; > > + > > + if (ufd) > > + put_user(-EPERM, ufd); > > + > > return error; > > + } I don't like this. It's bad enought that the generic file layer needs to call into __receive_sock() I don't want it to poke into other subsystems internals even more. That's just not appropriate. Get this out of the VFS's way, please.