Re: [dev] swc: A small Wayland compositor

From: Michael Forney <mforney_AT_mforney.org>
Date: Sun, 26 Jan 2014 00:38:36 +0000

On Fri, 24 Jan 2014 09:23:20 +0100, Silvan Jegen <s.jegen_AT_gmail.com> wrote:
> > This is very exciting. I hope to play with this in the next few days.
>
> I agree! I hope I'll find the time to look into the code base some

I've added a minimal example window manager in example/. It can be built
with "make example", and run with "launch/swc-launch example/wm". Note
that swc-launch needs either setuid root or to be run as root in order
to open input devices and to obtain DRM modesetting privileges.

Possible security concern: swc-launch passes opened input device file
descriptors to the user-specified display server process (which is run
with reduced privileges). However, it also switches to a new unused VT,
and revokes them when this VT is switched away from. One potential issue
with this is that it doesn't prevent a malicious program from pretending
to be swc-launch and starting a trusted display server to appear normal,
but underneath intercept any key presses. Though, I'm also not sure that
the situation is any better on X ("xev -id window-id" can dump input
events sent to window-id).

Weston solves this problem by hardcoding the display server path in
weston-launch. For swc, this would imply a separate launcher program for
each window manager, which doesn't seem like a good solution to me. On a
single-user development machine, it is quite convenient to be able to
run, for example, "swc-launch -- valgrind example/wm" to debug crashes.
However, I do see the potential risk. Another solution could be having a
configuration file in /etc containing a list of allowed display servers.

Thoughts?

-- 
Michael Forney <mforney_AT_mforney.org>
Received on Sun Jan 26 2014 - 01:38:36 CET

This archive was generated by hypermail 2.3.0 : Sun Jan 26 2014 - 01:48:04 CET