From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.sws.net.au (smtp.sws.net.au [144.76.186.9]) (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 22D8E1EEE6 for ; Sat, 13 Jun 2026 02:54:00 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=144.76.186.9 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781319242; cv=none; b=oTaGL2xJ2C3FP9cZZKEAptUr3Wlm8KFDv2hC30YmqLIQ3urqxeGFG6ScyKry1Vr8bWayF1V8RRmBgjY+60dEfTZdVx5KlfSc7HYPPM2QQP6e4WEpTl1eRmMDVFRpeYh9m8IqUgsRyW1CMm2a5/sk/QlhUivgD8HZGXQHOuCUiEg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781319242; c=relaxed/simple; bh=/D0qTGV6kTstAhoPvyntchUu3PQ2gIXruKsstjWVy+M=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=kaK9r764sCJV195FrWgmuO+4FPxcHGr2io8sqvohx4saoz9lIcZh3ac9tvhC9KAy169CJ9smYC6f+s3zNl7MdMvUtfpKahtAYbADrKm2Sl8QPJS5JTAm7jg3V37H0THQzjT1HGh3uUC+DYOKReMrX9sJ4y48UbWJb5F0foMzKpk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=coker.com.au; spf=pass smtp.mailfrom=coker.com.au; dkim=pass (1024-bit key) header.d=coker.com.au header.i=@coker.com.au header.b=DRY7ICX9; arc=none smtp.client-ip=144.76.186.9 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=coker.com.au Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=coker.com.au Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=coker.com.au header.i=@coker.com.au header.b="DRY7ICX9" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=coker.com.au; s=2008; t=1781319239; bh=MQ0ul6h27GqvAa/Ry6afXuYK3MYU/XfJJuXY6sFbtl8=; l=670; h=From:To:Reply-To:Subject:Date:In-Reply-To:References:From; b=DRY7ICX9PWlszuDVL8I5HOzOderNYwMmZDfT15npGuJwgw7qCuGlZWKYlCXou2R3P f7DrxcvVk8DKffnz0R6DUpgb9S8uwbpHzCwxrCgC0DOxhJhGeiRBqi0H4q19KXCIqe mYonRusxf+lLR0zE7MXKa8V0/C3MYXIL7XuAtHc8= Received: from xev.localnet (27-32-30-135.tpgi.com.au [27.32.30.135]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) (Authenticated sender: russell@coker.com.au) by smtp.sws.net.au (Postfix) with ESMTPSA id 3621715B9A; Sat, 13 Jun 2026 12:53:57 +1000 (AEST) From: Russell Coker To: "selinux-refpolicy@vger.kernel.org" , "Sugar, David" Reply-To: russell@coker.com.au Subject: Re: fs_rw_tmpfs_files(fwupd_t) Date: Sat, 13 Jun 2026 12:53:53 +1000 Message-ID: <2386758.tgW7RDIVbh@xev> In-Reply-To: References: <23366800.EfDdHjke4D@dojacat> Precedence: bulk X-Mailing-List: selinux-refpolicy@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="utf-8" On Saturday, 13 June 2026 01:15:33 AEST Sugar, David wrote: > The file in this case is a memfd file (created with memfd_create). You CAN > transition this from tmpfs_t to a private type (i.e. fwupd_tmpfs_t). I > just dealt with something like this for fapolicyd: > https://github.com/SELinuxProject/refpolicy/pull/1141 Though I never saw > denials for the create, the transition will work. Thanks for the information. This seems like a kernel bug. The domains in question aren't permitted to create tmpfs_t objects but the domains in question can create them anyway. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/