Bug 1768193

Your use of sudo for KDE 3 applications screwed up the socket permissions in your home directory. Try deleting the .DCOP* and .ICE* sockets/files in your home directory and then running ksensors again. And next time do not run GUI applications under sudo, use kdesu instead.

Hi Kevin,

sorry, but I had only one .ICE* (owners and group myself) and no .DCOP*

I removed the .ICEauthauthority, but it didn'change anything. 

It's not linked to selinux.

It seems linked to the Fedora 31 migration.

I believe this started at f31 upgrade, too (without any attempt to run GUI apps as root).

I have been unable to find a way to start dcopserver.

.xsession_errors:
/usr/bin/iceauth:  creating new authority file /run/user/1000/ICEauthority
DCOPClient::attachInternal. Attach failed Authentication Rejected, reason : None of the authentication protocols specified are supported and host-based authentication failed
ICE Connection rejected!

From command line:
$ dcopserver&         
[1] 8584
garry@tfr$ ICE Connection rejected!

DCOPClient::attachInternal. Attach failed Authentication Rejected, reason : None of the authentication protocols specified are supported and host-based authentication failed
ICE Connection rejected!

DCOPClient::attachInternal. Attach failed Authentication Rejected, reason : None of the authentication protocols specified are supported and host-based authentication failed
DCOPServer self-test failed

I created a new user; logged out; logged in as new user and examined new user's .xsession-errors to find exactly the same errors being noted.

I used to be able to run ksensors, but not any more due to this error.

Still not fixed in f32.

I have upgraded from F30 to F31 few days ago.
When I try to view an attached file in kmail I get the same error.
I also created a new user but I always get the same error.
Sorry for my bad english

What is the type of the attached file? This error should normally occur, if at all, only with legacy kdelibs3 applications. So I wonder with what application KMail is trying to open the file.

The type of files are images (most jpg) and pdf.
The programs are gwenview and okular.
With F30 this did not happen.

... and I haven't DCOP* and .ICE* sockets/files in my home directory

Sorry, one important thing: after the error message, okular or gwenview show the files.
I also tried with ksensors and I get the same error as  Pierre Juhen.
It is possible to upload some screenshots? If yes how is it possible?

Found it!

If I unset XDG_RUNTIME_DIR, I can start ksensors (or dcopserver, etc.).
Otherwise I get the "ICE Connection rejected!" error.

Reporting this to upstream is useless, kdelibs3 is no longer supported upstream.

It is clear that something must have changed recently, because XDG_RUNTIME_DIR has always been set (it was already set on F29, at least) and dcopserver worked fine.

Do you have SELinux enabled? If so, do you see an AVC error from SELinux? And can you try temporarily setting it to permissive (sudo setenforce 0)? (Or even disabling it entirely, though that requires a reboot, and if you wish to reenable it later, another reboot followed by a lengthy file system relabeling.)

Yes, I have selinux enabled.

Rebooting with selinux=0 doesn't change anything.

On my system :

[pierre@pierre ~]$ echo $XDG_RUNTIME_DIR
/run/user/1000

[pierre@pierre ~]$ ls -laZ /run/user/1000
total 4
drwx------. 8 pierre pierre system_u:object_r:user_tmp_t:s0        300 18 juin  06:54 .
drwxr-xr-x. 3 root   root   system_u:object_r:user_tmp_t:s0         60 18 juin  06:52 ..
srw-rw-rw-. 1 pierre pierre unconfined_u:object_r:user_tmp_t:s0      0 18 juin  06:52 bus
drwx------. 2 pierre pierre unconfined_u:object_r:config_home_t:s0  60 18 juin  06:52 dconf
drwx------. 2 pierre pierre unconfined_u:object_r:user_tmp_t:s0     40 18 juin  06:52 gvfs
-rw-------. 1 pierre pierre unconfined_u:object_r:user_tmp_t:s0      0 18 juin  06:54 ICEauthority
d---------. 3 pierre pierre system_u:object_r:user_tmp_t:s0        160 18 juin  06:52 inaccessible
srw-------. 1 pierre pierre unconfined_u:object_r:user_tmp_t:s0      0 18 juin  06:52 kdeinit5__0
drwx------. 2 pierre pierre unconfined_u:object_r:user_tmp_t:s0     60 18 juin  06:52 keyring
srwxrwxr-x. 1 pierre pierre unconfined_u:object_r:user_tmp_t:s0      0 18 juin  06:52 klauncherDmVcEa.1.slave-socket
-rw-rw-r--. 1 pierre pierre unconfined_u:object_r:user_tmp_t:s0     67 18 juin  06:52 KSMserver__0
srwxr-xr-x. 1 pierre pierre system_u:object_r:user_tmp_t:s0          0 18 juin  06:52 kwallet5.socket
srw-rw-rw-. 1 pierre pierre unconfined_u:object_r:user_tmp_t:s0      0 18 juin  06:52 pipewire-0
drwx------. 2 pierre pierre unconfined_u:object_r:user_tmp_t:s0     80 18 juin  06:52 pulse
drwxr-xr-x. 4 pierre pierre unconfined_u:object_r:user_tmp_t:s0    120 18 juin  06:52 systemd

Regards,

It looks like this was broken by this libICE change:
https://gitlab.freedesktop.org/xorg/lib/libice/-/commit/b484311c929a1b64966d89da92fafce7263006e1

Does this:
export ICEAUTHORITY="$HOME/.ICEauthority"
ksensors
help as a workaround?

DCOP has its own copy of authutil.c, which does not have this change, and so it does not find the file written by iceauth, which uses the system libICE with this change.

Looks like I need to backport:
http://mirror.git.trinitydesktop.org/cgit/tdelibs/commit/dcop/KDE-ICE?id=38b2b0be7840d868c21093a406ab98a646212de1

Actually:
http://mirror.git.trinitydesktop.org/cgit/tdelibs/commit/?id=38b2b0be7840d868c21093a406ab98a646212de1
changes even more than just DCOP.

http://bugs.pearsoncomputing.net/show_bug.cgi?id=3027

This affects libICE 1.0.10, hence Fedora 31 and upwards.

We may also need this in kdebase3:
http://mirror.git.trinitydesktop.org/cgit/tdebase/commit/?id=ed93cf0e084d52ca58c8a966fa9506af4484a8a9
though we do not ship the KDE 3 ksmserver executable, so it might not actually be needed.

I am sorry that I have not acted earlier on this. Unfortunately, the bug had several characteristics that made it look like a configuration error:
* Only one person had reported it, and nobody else had confirmed it for several months.
* The symptoms happened to match the ones of a frequent configuration error, where the ICEauthority file ended up owned by root due to the use of su/sudo, leading to dcopserver failing the same way.
* The suggested workaround actually used sudo, making it look even more like the above.
* The bug is not caused by a change in kdelibs3 itself (there wasn't any), but in libICE. As a result, the exact same kdelibs3 works fine with an older libICE (and I was not actually running F31 yet myself).

By the way, there must be an additional bug as per comment #4, because KMail should not be running anything depending on DCOP.

The additional bug (comment #4) seems to be yet another case of some KF5 Framework attempting to run a kdelibs3 binary from /usr/bin instead of the binary from /usr/libexec/kf5 it is supposed to run.

It looks like this was broken by this libICE change:
https://gitlab.freedesktop.org/xorg/lib/libice/-/commit/b484311c929a1b64966d89da92fafce7263006e1

Does this:
export ICEAUTHORITY="$HOME/.ICEauthority"
ksensors
help as a workaround?

DCOP has its own copy of authutil.c, which does not have this change, and so it does not find the file written by iceauth, which uses the system libICE with this change.


-------------------

Hi,

this workaround works 

Regards,

My guess is that comment #4 is a bug similar to bug #1512418, but with some other executable, possibly kioexec.

> this workaround works

Great.

I am building kdelibs3 and kdebase3 updates that should fix this permanently.

The bug from comment #4 is now filed as bug #1848491. That bug needs to be fixed in kf5-kio.

So, actually, the KDE 3 ksmserver should not be relevant, so I am not going to update kdebase3. kdelibs3 updates are now build, I am filing them in Bodhi.

FEDORA-2020-e7b4dbd0cd has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2020-e7b4dbd0cd

FEDORA-2020-0ad31a5893 has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-0ad31a5893

For the record, this is the fix (backported from Trinity tdelibs):
https://src.fedoraproject.org/rpms/kdelibs3/blob/master/f/kdelibs-3.5.10-libice-1.0.10.patch

FEDORA-2020-e7b4dbd0cd has been pushed to the Fedora 31 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-e7b4dbd0cd`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-e7b4dbd0cd

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2020-0ad31a5893 has been pushed to the Fedora 32 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-0ad31a5893`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-0ad31a5893

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2020-0ad31a5893 has been pushed to the Fedora 32 stable repository.
If problem still persists, please make note of it in this bug report.

FEDORA-2020-e7b4dbd0cd has been pushed to the Fedora 31 stable repository.
If problem still persists, please make note of it in this bug report.