https://bugs.kde.org/show_bug.cgi?id=359066
Bug ID: 359066
Summary: Plasma workspace freezes for 10 seconds upon selecting
text in an untrusted X11 session (e.g. ssh -X)
Product: plasmashell
Version: 5.5.3
Platform: Archlinux Packages
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: NOR
Component: general
Assignee: k...@davidedmundson.co.uk
Reporter: r...@robwu.nl
CC: bhus...@gmail.com, plasma-b...@kde.org
Created attachment 97046
--> https://bugs.kde.org/attachment.cgi?id=97046&action=edit
xscope output recording the events around text selection
After starting an untrusted X11 session (with the Security Extension enabled),
selecting text (=putting text on the PRIMARY clipboard) causes the plasma
workspace (taskbar, clock, desktops, desktop widgets, etc) to freeze and become
non-responsive to input for ten seconds.
In addition to the above, if I then try to READ from the clipboard (e.g. by
selecting text in another program, or using xsel), then the program that
initiates the clipboard read request freezes as well.
If I use "ssh -Y" instead of "ssh -X" (or "xauth -f /tmp/myauthfile generate :0
. trusted" instead of "untrusted"), then the problem does not occur.
Steps to reproduce:
1. Set up an untrusted X11 forwarding session, e.g. via "ssh -X localhost" (or
via xauth)
2. Open a program with text input, e.g. "kdialog --textinputbox x y"
3. Select text with the mouse
4. Release the mouse
5. Open the terminal and run xsel (OR go to a GUI program like Firefox or
Chrome and try to paste the contents of PRIMARY via the mousewheel).
Actual result:
After step 4, the plasma workspace is frozen for 10 (ten) seconds (can't
interact with taskbar, clock isn't ticking, etc.).
At step 5, xsel does not immediately return the clipboard (it does not exit
until I press ^C, I waited for at least one minute) (if you try to paste in a
GUI program, the program freezes)
Expected result:
At step 4 and 5, the UI should never freeze and become non-responsive.
At step 5, xsel should immediately return (might be a bug in xsel?).
Additional information:
I recorded the data over the X11 protocol using xscope and attached a fragment
as x11-select-freeze.log (cutting the head and tail of the logs, but anything
in between is not modified).
It shows that the ChangeProperty request was rejected with Access error. The
stderr of the original program (kdialog) shows a similar issue:
X Error: BadAccess (attempt to access private resource denied) 10
Major opcode: 18 (X_ChangeProperty)
Resource id: 0x4c0003f
Based on the above information, I think that the request was generated by
QXcbClipboard::sendSelection.
Here is the stack trace of the thread that seems to be busy when plasmashell is
frozen. I captured it right after step 4 using
$ sudo gdb -q -p `pidof plasmashell` -batch -ex 'thread apply all bt'
Thread 1 (Thread 0x7f3fe1021800 (LWP 29489)):
#0 0x00007f3fdb65fe23 in select () from /usr/lib/libc.so.6
#1 0x00007f3fcd7b8de0 in ?? () from /usr/lib/libQt5XcbQpa.so.5
#2 0x00007f3fcd7b93ff in ?? () from /usr/lib/libQt5XcbQpa.so.5
#3 0x00007f3fcd7baf00 in ?? () from /usr/lib/libQt5XcbQpa.so.5
#4 0x00007f3fdc2795a9 in QInternalMimeData::formats() const () from
/usr/lib/libQt5Gui.so.5
#5 0x00007f3f20caf700 in ?? () from
/usr/lib/qt/plugins/plasma/dataengine/plasma_engine_clipboard.so
#6 0x00007f3fdbf591a7 in QMetaObject::activate(QObject*, int, int, void**) ()
from /usr/lib/libQt5Core.so.5
#7 0x00007f3fdc5e6d1e in QClipboard::changed(QClipboard::Mode) () from
/usr/lib/libQt5Gui.so.5
#8 0x00007f3fcd7b9629 in ?? () from /usr/lib/libQt5XcbQpa.so.5
#9 0x00007f3fcd7c2048 in QXcbConnection::handleXcbEvent(xcb_generic_event_t*)
() from /usr/lib/libQt5XcbQpa.so.5
#10 0x00007f3fcd7c2b73 in QXcbConnection::processXcbEvents() () from
/usr/lib/libQt5XcbQpa.so.5
#11 0x00007f3fdbf5a1e1 in QObject::event(QEvent*) () from
/usr/lib/libQt5Core.so.5
#12 0x00007f3fdca2e9ac in QApplicationPrivate::notify_helper(QObject*, QEvent*)
() from /usr/lib/libQt5Widgets.so.5
#13 0x00007f3fdca33e86 in QApplication::notify(QObject*, QEvent*) () from
/usr/lib/libQt5Widgets.so.5
#14 0x00007f3fdbf2abab in QCoreApplication::notifyInternal(QObject*, QEvent*)
() from /usr/lib/libQt5Core.so.5
#15 0x00007f3fdbf2cfa6 in QCoreApplicationPrivate::sendPostedEvents(QObject*,
int, QThreadData*) () from /usr/lib/libQt5Core.so.5
#16 0x00007f3fdbf81143 in ?? () from /usr/lib/libQt5Core.so.5
#17 0x00007f3fd85d7dc7 in g_main_context_dispatch () from
/usr/lib/libglib-2.0.so.0
#18 0x00007f3fd85d8020 in ?? () from /usr/lib/libglib-2.0.so.0
#19 0x00007f3fd85d80cc in g_main_context_iteration () from
/usr/lib/libglib-2.0.so.0
#20 0x00007f3fdbf8154f in
QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) ()
from /usr/lib/libQt5Core.so.5
#21 0x00007f3fdbf2857a in
QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from
/usr/lib/libQt5Core.so.5
#22 0x00007f3fdbf3053c in QCoreApplication::exec() () from
/usr/lib/libQt5Core.so.5
#23 0x0000000000431304 in main ()
--
You are receiving this mail because:
You are watching all bug changes.
