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 9DB7A365A13 for ; Fri, 12 Jun 2026 14:34:53 +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=1781274895; cv=none; b=uMfdbYVLlyztTVXvJrKPs6VpjLh3tIgGlJ2h/wv160+z1Xqih+FkeJRSHxn1Fwroa4OyeEAWoMo1hiIB1YORhm5MOfZl6AYjf2aGk+jjZGGNdaDS5Uh2OEwd9fG3fm7nBmOmijhMe7pQayzv+997e5OquIq5W5+x611qZDijVkI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781274895; c=relaxed/simple; bh=KQaYs7Xp72QvUeomSUjZIdhqSiSguZJH983s3RZrkFc=; h=From:To:Subject:Date:Message-ID:MIME-Version:Content-Type; b=eEXvAYkmMbA/WUSTX/GGXS/Hqb3ak9qtuSYXchsQW8szf5zPZqkWQQSgi3f6pYYrkw8ZifKz+9D1uDI4zhgapAc2RZQWI1WVB5DBnfetnqEilOymHJJKSatJRwzL7OH7mo10USuSnsFgOYJpyfFgZ+HH+/gOjSiV/zynYRR9Cq0= 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=QTfGDrJX; 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="QTfGDrJX" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=coker.com.au; s=2008; t=1781274416; bh=X+DhKGQFS0so8uFrytytik11p6zCaFa5KkIPaS6EdQo=; l=2423; h=From:To:Subject:Date:From; b=QTfGDrJXtoPqlqBiESNBrynK9p+n7qDwuWrHk7dEwAW6s4HtBr8nQU0WAB5THSFGF EB1MWB5bJsWaTHsvS/VEvOCabmirm3jWqeQ6nBUsAzJMcHRNVuZcLeeWDpHd3Ap9BQ B/gAoLgC7XgK/s1uIzyu2+RGb7zvhLD2fHBIvEz8= Received: from liv.coker.com.au (unknown [IPv6:2001:4479:6501:a300:facb:5eb8:e3b3:893f]) (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 4C22C12EFC for ; Sat, 13 Jun 2026 00:26:55 +1000 (AEST) From: Russell Coker To: selinux-refpolicy@vger.kernel.org Subject: fs_rw_tmpfs_files(fwupd_t) Date: Sat, 13 Jun 2026 00:27:02 +1000 Message-ID: <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" The below ausearch output is from a system running Debian/Trixie (the current stable release) with kernel 6.12.88+deb13-amd64. The same thing happens with Debian/Unstable and kernel 7.0.10+deb14-amd64 but I expect people here are more interested in results from stable releases. What would this be about? type=PROCTITLE msg=audit(06/12/26 23:31:50.829:3771572) : proctitle=/usr/bin/ fwupdmgr refresh type=SYSCALL msg=audit(06/12/26 23:31:50.829:3771572) : arch=x86_64 syscall=write success=no exit=EACCES(Permission denied) a0=0xb a1=0x7fc07c06f010 a2=0x1c817c a3=0x0 items=0 ppid=1 pid=160767 auid=unset uid=fwupd-refresh gid=fwupd-refresh euid=fwupd-refresh suid=fwupd-refresh fsuid=fwupd-refresh egid=fwupd-refresh sgid=fwupd-refresh fsgid=fwupd-refresh tty=(none) ses=unset comm=fwupdmgr exe=/usr/bin/fwupdmgr subj=system_u:system_r:fwupd_t:s0 key=(null) type=AVC msg=audit(06/12/26 23:31:50.829:3771572) : avc: denied { write } for pid=160767 comm=fwupdmgr path=/memfd:fwupd (deleted) dev="tmpfs" ino=575756 scontext=system_u:system_r:fwupd_t:s0 tcontext=system_u:object_r:tmpfs_t:s0 tclass=file permissive=0 The command "sesearch -A -s fwupd_t -t tmpfs_t -c file" gives no output, so fwupd_t shouldn't be able to create a file of that type. What do you think is going on here? Is the kernel creating it with the default context for the tmpfs filesystem and then passing it to fwupd? I also see this from some other things such as the KDE screensaver: type=PROCTITLE msg=audit(06/13/26 00:16:02.972:18192) : proctitle=/usr/lib/ x86_64-linux-gnu/libexec/kscreenlocker_greet --graceTime 5000 --ksldfd 74 type=SYSCALL msg=audit(06/13/26 00:16:02.972:18192) : arch=x86_64 syscall=ftruncate success=no exit=EACCES(Permission denied) a0=0x1f a1=0x1000 a2=0x5 a3=0x7ffe1a5320e0 items=0 ppid=22905 pid=23368 auid=tv uid=tv gid=tv euid=tv suid=tv fsuid=tv egid=tv sgid=tv fsgid=tv tty=(none) ses=265 comm=kscreenlocker_g exe=/usr/lib/x86_64-linux-gnu/libexec/kscreenlocker_greet subj=user_u:user_r:xscreensaver_t:s0 key=(null) type=AVC msg=audit(06/13/26 00:16:02.972:18192) : avc: denied { write } for pid=23368 comm=kscreenlocker_g name=memfd:unknown-usage:QtQml dev="tmpfs" ino=5250 scontext=user_u:user_r:xscreensaver_t:s0 tcontext=user_u:object_r:tmpfs_t:s0 tclass=file permissive=0 -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/