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