> On Nov. 19, 2015, 1:26 p.m., Sebastian Kügler wrote: > > Possibly naive question: How would I use it with my custom-build setup, > > where I need vars like QT_PLUGIN_PATH, etc. set to be able to start the > > binaries at all?
I don't have a solution for it yet and yes it also affects my setup. I hope qt.conf can be used, but I don't know yet. - Martin ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/126115/#review88591 ----------------------------------------------------------- On Nov. 19, 2015, 1:22 p.m., Martin Gräßlin wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/126115/ > ----------------------------------------------------------- > > (Updated Nov. 19, 2015, 1:22 p.m.) > > > Review request for Plasma, David Edmundson and Matthias Klumpp. > > > Repository: plasma-workspace > > > Description > ------- > > Any environment variable which can be used to specify a path to a > binary object to be loaded in the KWin process bears the risk of > being abused to add code to KWin to perform as a key logger. > > E.g. an env variable pointing QT_PLUGIN_PATH to a location in $HOME > and adjusting QT_STYLE_OVERRIDE to load a specific QStyle plugin from > that location would allow to easily log all keys without KWin noticing. > > As env variables can be specified in scripts sourced before the session > starts there is not much KWin can do about that to protect itself. > > This affects all the LD_* variables and any library KWin uses and > loads plugins. > > The list here is based on what I could find: > * LD_* variables as specified in the man page > * LIBGL_* and EGL_* as specified on mesa page > * QT_* variables based on "git grep qgetenv" in qtbase and qtdeclarative > combined with Qt's documentation > * "git grep getenv" in various KDE frameworks based on ldd output of KWin > > Unfortunately the list is unlikely to be complete. If one env variable is > missed, there is a risk. Even more each change in any library might > introduce new variables. > > The approach is futile, but needed till Linux has a secure way to start > the session without sourcing env variable scripts from user owned > locations. > > > Diffs > ----- > > startkde/startplasmacompositor.cmake > 1e46e5be0a0d733fb01e1a87a34ee3c73a06bf8c > > Diff: https://git.reviewboard.kde.org/r/126115/diff/ > > > Testing > ------- > > > Thanks, > > Martin Gräßlin > >
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
