Nov 09 12:36:07 censoredservername audit: ANOM_ABEND auid=500 uid=500 gid=1000 ses=14 pid=29557 comm="gnome-session-b" exe="/usr/libexec/gnome-session-binary" sig=5 Nov 09 12:36:07 censoredservername gnome-session: aborting. Nov 09 12:36:07 censoredservername gnome-session: gnome-session-binary: ERROR: Failed to connect to system bus: Could not connect: Permission denied Nov 09 12:36:07 censoredservername gnome-session: gnome-session-is-accelerated: llvmpipe detected. Nov 09 12:36:07 censoredservername : SpiRegistry daemon is running with well-known name. Nov 09 12:36:07 censoredservername : dbus-daemon: Successfully activated service '' Nov 09 12:36:07 censoredservername : dbus-daemon: Activating service name='' requested by ':1.0' (uid=500 pid=29598 comm="/usr/libexec/gnome-session-check-accelerated ") Nov 09 12:36:07 censoredservername : ** (process:29602): WARNING **: Failed to register client: GDBus.Error.ServiceUnkn own: The name was not provided by any. Nov 09 12:36:07 censoredservername dbus-daemon: Successfully activated service '' Nov 09 12:36:07 censoredservername dbus-daemon: Activating service name='' requested by ':1.6' (uid=500 pid=29598 comm="/usr/libexec/gnome-session-check-accelerated ") Nov 09 12:36:07 censoredservername dbus-daemon: Activating service name='' requested by ':1.1' (uid=500 pid=29584 comm="gsettings get region ") Does anyone have any suggestions as to what to look at next? I am almost certain this is a filesystem permissions issue. When I look in journalctl, I see the following. This only stopped working for me after disconnecting my vnc session so I suspect this will affect all new sessions, hence my hesitation to reboot. The system hasn't been rebooted since the permission issue and subsequent repair, and there are still functioning gnome desktop sessions logged in and working locally. I haven't had the nerve to restart the dbus daemon since repairing setuid as I am remote through SSH and don't want to lose access to the system, or break any existing working sessions (and I believe it should not be necessary to do so in this scenario). That is when I first found that the dbus daemon setuid bit was gone. But then I was greeted by a blank session window with no cursor. Since I tunnel through SSH I disabled encryption on the connection for now to work around it. I suspect though that there is still damage as today while working remote I couldn't get vnc server to function, it was throwing a TLS error. This caused some interesting behavior, like whacking the setuid bits on 'su' and 'dbus-daemon-launch-helper', which I have since repaired. I ran a loop to list all packages using rpm -qa and run rpm -setperms and -setugids on all installed packages. I had an issue where a LOT of files on the system had their ownership overwritten (chown -R is not your friend in certain situations).
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |