On 04/09/17 01:46, Martin Gräßlin-san wrote:
Am 2017-04-08 17:26, schrieb Weng Xuetian:
You're wrong about the QT_IM_MODULE stuff. To make application to use the
wayland protocol to type (text-input), the implementation must be done with
QT_IM_MODULE=wayland. I don't mind if it is set to certain application but set
it in general won't work. Also to have real virtual keyboard , you need to let
the input method daemon to provides a virtual keyboard implementation.
No you are wrong about that one :-) It might be that it used to be like that,
but Wayland is the default if no QT_IM_MODULE is specified. See
https://code.qt.io/cgit/qt/qtwayland.git/tree/src/client/qwaylandintegration.cpp#n142
And also, merging more and more daemon into kwin is not always good even from
security point of view. The problem is, once it got merged, the whole memory
space is being exposed. Which means, if there's a single piece of code is
vulnerable, it will affect the whole compositor. We are not perfect people, and
that's why put more code together will make it more vulnerable to attacker. If
you consider that, your prevention of ptrace on kwin becomes nothing and so
does your effort to make kwin not loading some random plugin (prevent
ld_preload and qt_plugins_path?).
The security of the system breaks with the weakest link. Whether the IM daemon
is insecure by running standalone or inside KWin isn't a difference.
I think the weakest link still can make more secure in the protocol.
I'd suggest to make Plasma Wayland with the current IM modules in the first
stage since I guess there will be many regressions in Plasma Wayland.
Currently I'm also involved a discussion how to secure the DBus in the GNOME
side and I also think it could be utilized for Plasma Wayland.
Otherwise I think it might be difficult to support Plasma in some distributions.
Wayland staffs has contributed in the IBus and GNOME connection for a long time
ago.
https://github.com/ibus/ibus/tree/master/client/wayland
But it's not used in GNOME yet.
