Bug 2560255

Are you sure such a change came in with this package version?

I cannot see any reason in the list:

    * Tue Oct 20 2026 Zdenek Pytela <zpytela> - 45.22-1
    
    - Allow systemd-oomd signull systemd-resolved
    - Allow login_userdomain watch localization files for changes
    - Allow login_userdomain mounton gnome generic data home dirs
    - Label /run/gnome-remote-desktop with gnome_remote_desktop_var_run_t
    - Allow systemd_nsresourced_t setuid/setgid inside a userns (bsc#1285095)
    - Allow access to systemd-nsresourced runtime socket (bsc#1284651)
    - Allow smbd watch public directories used for file transfer services
    - Allow sshd-session read systemd-nsresourced runtime socket file
    - Allow chrome_sandbox_t map its private tmpfs files
    - Allow sysadm_t to create iSCSI netlink sockets
    - Allow ktlshd connect to pcscd over a unix stream socket
    - Add iptables_dontaudit_read_var_run_dirs() interface
    - Allow polkit-auth read systemd-nsresourced runtime socket file
    - Allow systemd-nsresourced the sys_admin capability

Additionally, I can't see why a deamon would need to list the content of /home.

After downgrading some selinux versions I found it was the openssh update causing the issue.

Currently hitting F46 and F45 testing:

ssh *** "rpm -q selinux-policy openssh; ssh-add -l"
selinux-policy-45.20-1.fc45.noarch
openssh-10.5p1-1.fc45.x86_64
2048 SHA256:***

ssh *** "rpm -q selinux-policy openssh; ssh-add -l"
selinux-policy-45.20-1.fc45.noarch
openssh-10.6p1-1.fc45.x86_64
Could not open a connection to your authentication agent.


Related SELinux logs found:


#============= sshd_session_t ==============

#!!!! This avc can be allowed using the boolean 'polyinstantiation_enabled'
allow sshd_session_t home_root_t:dir read;

#!!!! This avc is allowed in the current policy
allow sshd_session_t ssh_home_t:sock_file create;

#============= sshd_t ==============

#!!!! This avc can be allowed using the boolean 'ssh_sysadm_login'
allow sshd_t unconfined_t:process signal;

FWIW I just successfully avoided this permission issue by moving my RemoteForward unix socket to this subdirectory: remote_fedora:$HOME/.ssh/ 

This looks like a more secure location anyway, so maybe I should have been doing that the whole time? Dunno, SELinux is too complicated to tell what is more secure vs not :-)

rpm -q selinux-policy openssh

selinux-policy-44.11-1.fc44.noarch
openssh-10.2p1-16.fc44.x86_64

Where did you have it before?

It was in $HOME/

sealert -l ...

SELinux is preventing sshd-session from create access on the sock_file .emacserver.socket.

*****  Plugin catchall (100. confidence) suggests   **************************

If you believe that sshd-session should be allowed create access on the .emacserver.socket sock_file by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# ausearch -c 'sshd-session' --raw | audit2allow -M my-sshdsession
# semodule -X 300 -i my-sshdsession.pp


Additional Information:
Source Context                system_u:system_r:sshd_session_t:s0-s0:c0.c1023
Target Context                system_u:object_r:user_home_dir_t:s0
Target Objects                .emacserver.socket [ sock_file ]
Source                        sshd-session
Source Path                   sshd-session
Port                          <Unknown>

Source RPM Packages           
Target RPM Packages           
SELinux Policy RPM            selinux-policy-targeted-44.11-1.fc44.noarch
Local Policy RPM              selinux-policy-targeted-44.11-1.fc44.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing

aw Audit Messages
type=AVC msg=audit(1792952919.656:1035): avc:  denied  { create } for  pid=14839 comm="sshd-session" name=".emacserver.socket" scontext=system_u:system_r:sshd_session_t:s0-s0:c0.c1023 tcontext=system_u:object_r:user_home_dir_t:s0 tclass=sock_file permissive=0

Hash: sshd-session,sshd_session_t,user_home_dir_t,sock_file,create

Proposed as a Blocker for 45-final by Fedora user pbrobinson using the blocker tracking app because:

 Issues with remote management with ssh

For what it's worth, the example in the Emacs manual suggests location `$HOME/.emacs.socket` for this file (on the basis that creating it anywhere else may require an extra round-trip to `mkdir -p` that directory).

https://www.gnu.org/software/emacs/manual/html_node/emacs/emacsclient-Options.html#:~:text=%E2%80%98%2DT%20tramp%2Dprefix%E2%80%99

Discussed at 2026-10-29 Fedora 45 Go/No-Go meeting, acting as a blocker review meeting: https://meetbot-raw.fedoraproject.org/meeting_matrix_fedoraproject-org/2026-10-29/f45-final-go-no-go-meeting.2026-10-29-18.02.html . Rejected as a blocker as there's no indication that this violates release criteria.

I guess it should be expected that this broke agent forwarding too? It's kind of frustrating for this to regress so quickly after it was fixed once.

On Fedora 44, agent forwarding is _not_ broken at the same time. The socket is (successfully) created inside fedora_remote:$HOME/.ssh/

ssh fedora_remote 'echo $SSH_AUTH_SOCK'
$HOME/.ssh/agent/s.___.sshd.___


> It's kind of frustrating for this to regress so quickly after it was fixed once.

If it's not tested then it's not working...

-----------

> For what it's worth, the example in the Emacs manual suggests location `$HOME/.emacs.socket` for this file 

That's only one (simple) location example and I couldn't find in that doc any explicit recommendation to place it in $HOME (or anywhere else).

> (on the basis that creating it anywhere else may require an extra round-trip to `mkdir -p` that directory).

I could not find that in the doc either. I tested it and it seems incorrect, there is no such auto-mkdir. It fails instead:

sshd-session: error: unix_listener: cannot bind to path $HOME/.ssh/testsubdir/emacserver.socket: No such file or directory


This entire Emacs discussion is somewhat off-topic because nothing in this bug seems Emacs-specific. This being said, if anyone wants to reproduce with Emacs (NOT convenient and not recommended unless you already use Emacs!), then don't forget you also need "StreamLocalBindUnlink yes" on the ssh server side. I'm mentioning StreamLocalBindUnlink because: 1) it's not easy to discover 2) it can definitely make this bug even more obscure.

(In reply to MarcH from comment #10)
> On Fedora 44, agent forwarding is _not_ broken at the same time.

It's broken on F-45, I'm seeing the same issue as Neal.