Ubuntu unveils its next-generation shell and display server [LWN.net]

Ubuntu unveils its next-generation shell and display server

Posted Mar 6, 2013 23:30 UTC (Wed) by neilbrown (subscriber, #359)
Parent article: Ubuntu unveils its next-generation shell and display server

Thanks for a well balanced article!

I'm having trouble sorting out the issue of "privilege protocols" though.

It seems to me that a "normal application" should only need to allocate one or more windows, draw on those windows, suggest where those windows should be on the display, and receive input events destined for those windows.

Other operations like grabbing all events and synthesising new events and making a window full-screen-with-no-decoration are needed for a window-manager or session manager, but are not needed for a "normal application" and so should not be available (principle of least privilege).

So I can well imagine there might be two protocol and only designated clients would be able to use the second protocol.

What I don't understand is why Ubuntu would say that the privilege requirement is a problem (especially as one of their complaints about X is that an unprivileged app can muck around with the input event stream arbitrarily) and I cannot see why Wayland people would say that the second protocol isn't privileged, when you clearly don't want just-any-app to be able to have control of every-window-on-the-display.

So I guess people are using the word "privilege" in some way subtly different to the way I'm using it.

Can someone explain?

(Log in to post comments)

Ubuntu unveils its next-generation shell and display server

Posted Mar 7, 2013 1:08 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]

> Other operations like grabbing all events and synthesising new events and making a window full-screen-with-no-decoration are needed for a window-manager or session manager, but are not needed for a "normal application" and so should not be available (principle of least privilege).

If I'm playing a HD video on a HD display, I really don't want to loose pixels around the edge and force the entire video to be rescaled. I really want my media player app to be able to go full-screen with no decorations.

synthesizing new events is also a very useful thing to be able to do. I created the Kiosk configuration that we used at Scale for the signs. It was a pretty simple "point a browser at a page and let it run", but it required both "full screen with no decorations" and "synthesizing new events", the first to make the page look right on the screen, and the second to move the mouse pointer out of the center of the screen so that it didn't obstruct and distract from the page being displayed.

note that I haven't read the article yet, and so I can't comment on the rest of your privilege questions, but the simple "why would anything other than a window-manager or session manager need to do this" question is one I wanted to comment on.

David Lang

Ubuntu unveils its next-generation shell and display server

Posted Mar 7, 2013 1:26 UTC (Thu) by neilbrown (subscriber, #359) [Link]

Your media player should certainly be able to *request* full screen. It is up to the policy of the session manager whether to allow that, and how to break out of that.

Your Kiosk essentially *is* a session manager. It says "That window should be full screen, and hide the mouse cursor". You don't want apps from $UNTRUSTED_SOURCE to be able to do that, but you as system owner should certainly be able to do that.

Ubuntu unveils its next-generation shell and display server

Posted Mar 7, 2013 1:37 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]

I agree, but if you require that only 'special' apps be written to use a particular api, then I as the admin loose any ability to use an app that way (without having to recompile it to use the new API)

Ubuntu unveils its next-generation shell and display server

Posted Mar 7, 2013 17:09 UTC (Thu) by amaranth (subscriber, #57456) [Link]

You can't go fullscreen without the window manager's permission right now anyway, how is this any different? Sure, your window manager never says no but it certainly could (and even force your window size back down if you tried to make it "fullscreen" anyway).

Ubuntu unveils its next-generation shell and display server

Posted Mar 19, 2013 14:44 UTC (Tue) by Duncan (guest, #6647) [Link]

While I've not tried the fullscreen thing specifically, kwin's window rules do allow kwin to force many things, including window size and position, border toggle state, etc.

Actually, come to think of it I KNOW the fullscreen thing can be forced, as kde 4.10 now includes a kwin scripting ability, with one of the two shipped scripts being a "video wall" script that forces selected media app windows to fullscreen to all monitors instead of just one, when they go to fullscreen mode. So it could certainly deny fullscreening at all, as well.

(Of course kde being kde, the activation of this script is a configuration option. FWIW, I turned off the other script, but like this one enough to have patched it to apply to smplayer2, it applied to smplayer, vlc, and one or two others, originally, but not to smplayer2 without the patch, which here on gentoo I apply by simply dropping it in the appropriate /etc/portage/patches/ subdir so it's applied each time I update the app. I should submit it upstream, but I already submitted patches for superkaramba that have just sat on the open bug, no comment or any indication at all that anyone's even read them since I submitted them for 4.5 or whatever, thus years ago. That tends to be a bit of a disincentive to even bother filing any further kde patch-bugs. =:^( )

So sometimes the window manager /does/ at least redefines "fullscreen" to suit its own purposes. =:^)

Ubuntu unveils its next-generation shell and display server

Posted Mar 19, 2013 16:11 UTC (Tue) by boudewijn (subscriber, #14185) [Link]

Keep in mind that KDE is not a group of a few hundred interchangeable resources that at all times work on all the projects. People work on their own area -- I never, no matter how much the temptation, have worked on kmail, for instance. The superkaramba project likely lost all activity when Plasma started supporting widgets. I don't know who the developers were, or where they went, but that superkaramba bugs don't get attention doesn't mean kwin bugs don't get attention.

The kwin team is really pretty active, and pretty responsive.

Ubuntu unveils its next-generation shell and display server

Posted Mar 7, 2013 10:25 UTC (Thu) by renox (subscriber, #23785) [Link]

I totally agree with you that normal applications should be able to go full screen, but I don't understand your use case for input event generation (that is the core of the security issue).
You wrote: "to move the mouse pointer out of the center of the screen so that it didn't obstruct and distract from the page being displayed."
so when you clicked on your media player it moved the mouse pointer?? Why didn't you just hide the mouse pointer if it stays idle a few seconds?
That's what most media player do and this doesn't require input event generation..

Ubuntu unveils its next-generation shell and display server

Posted Mar 7, 2013 11:12 UTC (Thu) by hummassa (subscriber, #307) [Link]

> I totally agree with you that normal applications should be able to go full screen,

I don't. At least not without some kind of overlay (*). The minute a normal application can go fullscreen it can spoof security measures (for instance, ask the user for his password and store/send it somewhere).

(*) One possible solution here is an OSD overlay that can be shown for a limited time, like two to five seconds, after any input -- keystroke, mouse move &c and, after that, vanish (like youtube's and xbmc's fullscreen mode video controls). This way the user can watch a video or even read a book or a webpage using the whole screen estate but can't be deceived in thinking its login page &c is being displayed.

Ubuntu unveils its next-generation shell and display server

Posted Mar 7, 2013 11:33 UTC (Thu) by renox (subscriber, #23785) [Link]

>> I totally agree with you that normal applications should be able to go full screen,
> I don't. At least not without some kind of overlay.

It depends on the situation.. On your home PC, is-it really an issue?
To fool you into entering your password, the trojan must be able to replicate somehow your environment, which is quite difficult if it isn't allowed to generate input events (like Wayland does).
Where security is important, I think that it should be possible by administrators to disable full screen windows.

Ubuntu unveils its next-generation shell and display server

Posted Mar 7, 2013 19:39 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]

> You wrote: "to move the mouse pointer out of the center of the screen so that it didn't obstruct and distract from the page being displayed."
so when you clicked on your media player it moved the mouse pointer??

There was no mouse or keyboard attached to the machine. There was no media player software running, just firefox viewing a HTML/javascript page.

I used a command-line tool (xwit) to inject a mouse movement action into the input event queue

Ubuntu unveils its next-generation shell and display server

Posted Mar 7, 2013 2:23 UTC (Thu) by hoegsberg (guest, #57768) [Link]

We have a "wl_shell" interface in the wayland protocol, which provides the means by which applications set window titles, icons, go fullscreen, pop up menus. This interface is not privileged, it's available to all clients.

We have another interface called "desktop_shell". This is a weston specific, private interface, only available to a special helper client that weston launches. This client provides the background and panel surface back to weston through this interface. Similarly, our input method helper is launched by weston and injects input events back into weston using a privileged interface only available to that client.

The way we've split weston into different processes is not a requirement of wayland. The wayland protocol and core libraries doesn't dictate that a compositor should split all UI into external processes. Weston works that way because we don't have a toolkit inside weston. On the other hand, GNOME Shell, for example, uses clutter inside the compositor and can do much UI in the compositor process as a wayland compositor.

The Unity/Mir developers want to build the Unity UI into the compositor (as explained in the UDS Mir video), similar to how GNOME Shell would work. Their concern about the privileged shell interface and external helper clients seems to be that they think it's the only way to structure a wayland compositor.

Ubuntu unveils its next-generation shell and display server

Posted Mar 7, 2013 2:44 UTC (Thu) by neilbrown (subscriber, #359) [Link]

Thanks. That's very helpful.

If I might summarize:
- All *wayland* APIs are non-privileged. However they do not allow you to implement (e.g.) a panel or screen saver.
- Weston has a private and privileged API which can be used to implement a panel etc.

The (current) MirSpec says two things about "privilege".
Firstly "We want to avoid exposing any sort of privileged protocol to client applications." Neither Wayland or Weston do this anyway. Weston only exposes a privileged API to processes that it executes directly.

Secondly "As another example, we consider the shell integration parts of the protocol as privileged and we'd rather avoid having any sort of shell behavior defined in the client facing protocol."
I'm not really sure what this means. It could be taken to say "Stuff like wl_shell should be privileged", but that contradicts the earlier point, so is unlikely to be the intention. So it probably means "desktop_shell" shouldn't be part of the client-facing protocol, and that is exactly the case - it isn't.
So I agree that they seem to be confused. I wonder if anyone from Mir is reading and cares to comment.

"wl_shell" is and should be unprivileged.
"desktop_shell" is an implementation detail of weston, and is not client-facing so questions of privilege are irrelevant.

Thanks.