> 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?
> 
> Martin Gräßlin wrote:
>     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.
> 
> Matthias Klumpp wrote:
>     A possible solution to that problem is to allow setting this in a 
> system-wide configuration file, or create a special KDE-specific 
> configuration which sets the script to a "debug mode", which doesn't filter 
> env vars.
>     The important thing is that you need root access to modify these settings 
> (set it to debug mode or set additional variables).

Wouldn't specifying them in /etc/profile.d/ work?

Currently I use it and it works fine:
```
$ cat /etc/profile.d/kde5.sh 
source ~kde-devel/kdescripts/deploykde5.sh
```


- Aleix


-----------------------------------------------------------
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

Reply via email to