Bug 2523504

Summary:	Newest update to selinux breaks ssh
Product:	[Fedora] Fedora	Reporter:	fygdxcyw
Component:	selinux-policy	Assignee:	Zdenek Pytela <zpytela>
Status:	MODIFIED ---	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	high	Docs Contact:
Priority:	unspecified
Version:	44	CC:	dwalsh, fedora-kernel-selinux, lvrabec, mmalik, omosnacek, pkoncity, ppywlkiqletw, vmojzis, zpytela
Target Milestone:	---	Keywords:	Regression, Reopened, SELinux
Target Release:	---	Flags:	fygdxcyw: needinfo? (fedora-kernel-selinux) fygdxcyw: needinfo? (zpytela)
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	---
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2026-09-11 09:42:25 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description fygdxcyw 2026-08-25 14:44:42 UTC

After updating selinux-policy and selinux-policy-targeted to 0:44.7-1.fc44, my sshfs broke. I could not figure out what exactly changed that caused this breakage, but I had a lot of permission denied errors, that went away after downgrading these two packages from 44.7-1.fc44 to 0:43.2-1.fc44 on host and client machines.

Please let me know if you CAN'T reproduce, so I can try and find more information about this.

Reproducible: Always

Steps to Reproduce:
1. update packages to 44.7-1.fc44
2. something about ssh public key authentication stops working 
Actual Results:
sshfs starts to not work

Expected Results:
sshfs to keep working

Comment 1 Villy Kruse 2026-08-26 06:04:02 UTC

Probably a variant of Bug 2523732 

But a copy of the AVC lines from /var/log/audit/audit.log could be useful.

Comment 2 Zdenek Pytela 2026-08-31 08:46:55 UTC

Please update to selinux-policy-44.8-1.fc44 and if the issue persists, attach output of

ausearch -i -m avc,user_avc,selinux_err,user_selinux_err -ts today

Comment 3 fygdxcyw 2026-09-01 10:14:58 UTC

I updated server and client to selinux-policy-44.8-1.fc44, but the issue persists. Here is the output of "ausearch -i -m avc,user_avc,selinux_err,user_selinux_err -ts today":

# When sshfs is working with an older version of selinux-policy:

----
type=AVC msg=audit(09/01/2026 ##:06:17.357:6913950) : avc:  denied  { search } for  pid=37526 comm=sshd-session name=/ dev="dm-4" ino=256 scontext=system_u:system_r:sshd_session_t:s0-s0:c0.c1023 tcontext=system_u:object_r:unlabeled_t:s0 tclass=dir permissive=1
----


# When sshfs not working with selinux-policy-44.8-1.fc44:

----
type=AVC msg=audit(09/01/2026 ##:41:27.155:158) : avc:  denied  { getattr } for  pid=3924 comm=sshd-session path=/servername/.ssh/authorized_keys dev="dm-1" ino=17094554 scontext=system_u:system_r:sshd_session_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:default_t:s0 tclass=file permissive=0
----
type=AVC msg=audit(09/01/2026 ##:41:30.294:165) : avc:  denied  { getattr } for  pid=3926 comm=sshd-session path=/servername/.ssh/authorized_keys dev="dm-1" ino=17094554 scontext=system_u:system_r:sshd_session_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:default_t:s0 tclass=file permissive=0
----

Comment 4 Zdenek Pytela 2026-09-07 15:16:54 UTC

Both unlabeled_t and default_t indicate an issue with labeling.

The unlabeled_t label is usually displayed when a file was created in SELinux disabled state or when its actual label does not currently exist.

The default_t type is assigned to filesystem objects that do not match any pattern in file-context configuration.

Comment 5 Villy Kruse 2026-09-08 06:21:02 UTC

Besides, the name "/servername" seems a bit unusual for a home directory.  sshfs works if the home directory is a subdirectory of /home.

Comment 6 Zdenek Pytela 2026-09-11 09:42:25 UTC

I just suggest to update, new builds should be available on Monday.

Comment 7 fygdxcyw 2026-10-03 10:01:06 UTC

I just got around to testing version 44.11-1.fc44 of selinux-policy and selinux-policy-targeted, and I'm sorry but it is still broken.

Downgrading to 43.3-1.fc44 however, makes it work again.

So something changed between 43.3-1.fc44 and 44.7-1.fc44 , that must have introduced this regression.