-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 04/01/14 11:01, Martin Graesslin wrote: > I will try to share my thoughts so far and I must say that I don't know > whether that's implementable at all. Of course we also thought about working with full paths, but I don't think that's a good solution for a flexible desktop environment such as Plasma. Only the initial application needs a configuration file with a full path. As far as I understand, this application could simply be a stub that executes the real application. The responsibility is then moved to the stub to decide whether an application (such as a Plasma widget, I suppose) can be trusted. This means all the complexity doesn't need to be built into the compositor. > Also it creates a terrible linear chain in the startup - we want to move to a > more flexible framework and don't turn KWin into another system startup process. It might be a solution for things like KSnapshot but certainly not to bring up the desktop shell. In the proposed design, the compositor only launches applications after being told to do so by other applications. So KWin wouldn't be the startup process, it would simply act as a proxy - much like klauncher, actually. > The idea I have so far is to depend on cgroups and namespaces. Thus > everything which needs the more privileged interfaces needs to be in the "desktop shell" cgroup. I hope that we can make use of systemd to provide us such features. Clients which are not in the trusted group will not get the more exposed interfaces. It would be a powerful solution, but it would make Wayland depend on systemd and Linux-specific features. > This could also work for things like screenshooters, but here we start to > enter trust issues again. We certainly would trust a KDE application, but that's already quite borderline. For such cases so far I only have the idea of nag screens like UAC. I hate that and absolutely don't want to implement it. So I'm looking forward for good solutions. Polkit could be a nice solution to that. Only if polkit is configured with enough action files to whitelist specific applications, and at that point you end up with pretty much the same configuration file system that was proposed originally. Polkit without proper configuration would be no better than UAC. > I'm not so sure about configuration files as I don't believe in whitelists in > general :-) Obviously it allows the distribution to properly setup the system but there might be better solutions to that. My suggestion here is to specify the interfaces in the desktop file. It would not be a global whitelist maintained by the sysadmin, it would be a bunch of config files installed by the applications themselves (assuming applications are installed by root, which to me seems like a reasonable assumption because that's what all the package managers do). I don't think specifying interfaces in the desktop file is any different from specifying them in a Wayland-specific config file, but I think it will complicate things. It will mean that many desktop files will have to be rewritten: you can't specify a Qt binary as the application, because Qt has a number of command-line arguments that can be abused. As I said a few mails back, the application would have to be a stub (e.g. a simple bash script) that filters the command-line arguments and only allows those that are safe. Additionally, if the interfaces are defined in the desktop file, then any application that uses desktop files (AFAIK that includes applications like Firefox, and of course various desktops, panels, widgets, launchers etc.) would have to be Wayland-aware and launch applications that need more privileges through the Wayland compositor rather than the normal way. And there's another problem: Most desktop environments allow you to put desktop files on the desktop. Not links to desktop files, but actual copies of the desktop file. The user can simply modify the desktop file and allow any interface he wants - and so can a malicious program. It could be argued that copying desktop files was a bad idea in the first place, but this is how things are currently being done. However, if we keep the desktop files and Wayland config files separately, then the desktop file can point to a bash script that will execute the application through the Wayland compositor. This keeps launching desktop files simple. In my opinion desktop files and Wayland config files have a very different purpose. The desktop files are there for convenience, they are simply shortcuts for common actions that would otherwise require a terminal. The Wayland config files OTOH are a security feature. I don't think the two should be mixed. Maarten Baert -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSyDsrAAoJEAeyXy8uXJOQchwP/A1eqdfjg8jBhfx3KLiMzg5Z otKO8U7QEHBVsdf68eu9zicaG5LwA7cszyjI4zEiNyBwMUgbM2VyHp33kr/D+c0X 6vApG4KHAxo1zDFR0Xp3MVGaTBRFLV3lEO9yxXukHARtS6jMfUhx729XpWGfcmPd KMNFoxYtmSKfeWZ/lJzGYQC+QNSa6hTsYWcfjW9k5FPwsgE5nEs7JkZwwEQ0VnE7 fR1Se4hrCwkiLvVYOKiaA7w2dBjmd9tCZrDODuIbPe4TNUt0jsrMv/9eiUcMdveS /oNEL2QgLLQzKzbOGi195IlrudCDSFLbSmw/kV9l9owg+X1tKLAQOz9X6R1WDe+F eqjZeIGAHofxOASlpZVXc1x9YaS3jk/U7s6LnWe08hCMOseoZUuzufOVgzEDPKuj 1Xvbx4nzaasngW4Cu3mIriOx1BJmXyJCKzcYN4F4OV715R+niRoGP/5RXFbrHynX JPpElwZ9pJYSXVobRCMYMSlXel9KI1eSIAVu0rr0eu+LrXJZzKeEGN5C/yvX4ptO Opg5tpIABGPe4KgI6nLM5rzHu8rpgERC56nTDuDlaGa8KZNTBoLRaoV0otG2ggA2 x7cGmpeEHTwkOQ0cykjLscUSsQZVNLbkwi6IzdWiuOSXVZWwzQq+1aSMzPB58jd8 HpguioqSpotOXbW/IkdP =Kuvc -----END PGP SIGNATURE----- _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
