Authorized clients

[Martin Peres]

On 07/01/2014 20:43, Pekka Paalanen wrote:
> On Tue, 7 Jan 2014 14:26:36 -0500
> "Jasper St. Pierre" <jstpierre at mecheye.net> wrote:
>
>> On Tue, Jan 7, 2014 at 9:07 AM, Martin Peres
>> <martin.peres at free.fr> wrote:
>>
>>> Would it be ok for you if the compositor asked the user to
>>> agree for the program to
>>> do the operation? If so, we can guarantee that this is really
>>> the user's intent and
>>> allow the application. We can also add a security warning with
>>> a "Do not ask again"
>>> checkbox. Would it be satisfactory to you?
>>>
>> The user opened up a screen recording app. The user's intent is
>> very much to record the screen. We don't need to ask the user
>> again with a prompt.
> For just screenshooting and recording, how about a simple setting
> "allow all programs capture the screen? yes/no" in the compositor's
> configuration dialog? Since it sounds like any automatic
> authentication/authorization scheme is going to hit cornercases.
>
> With that, write a screenshooting protocol interface, that is
> bindable for all clients, and informs the client whether capturing
> at will is allowed or not. When not, the client can show an
> informational message "Screen capturing is disabled in your
> compositor preferences."
>
> Make that support dynamic enable/disable and make access denied a non-fatal error.
What I like about your dynamic enable/disable idea is that there is no 
storage
of the settings that could be abused by other apps (since they are usually
run with the same user as the compositor). If we want to make the setting
permanent (for whatever stupid reason one may have), it should require
root access to store this setting.

I think making sure the user really is the one who launched the app (by 
letting
the compositor launch it for us) is really a lesser evil and should 
cover all the
cases. No need to add complexity by creating new protocols to require
privileges (I already implemented one and it is hard to make it right, 
and I'm not
even talking about the fact it requiring a policy!).

I think the screenshot API and the video recording one should be separate.

For the configuration of the screenshot, I see two cases. Either we just 
want
the compositor to grab the image and pass it to an application [1] or we 
want
the screenshotting app to be able to be able to query the number of 
screens and
windows and their positions. The first doesn't require a Wayland 
protocol, the
second does however require a privileged protocol.

If we go for the second solution (which could make sense for other use 
cases),
we should limit the number of screenshots the app can make, otherwise we
cannot make sure the app really exited and is not grabbing the screen 
all the
time. I am however willing to live with that if the default-screenshot 
app can
only be changed as root or as a run-time change. Another possibility would
be to advise to use [1] by default and the second solution would be the
less-secure fallback that doesn't restrict the user much.

Any thoughts?

As for the video grabbing API, I see the same solutions. Different 
hotkeys could
automatically grab the screen content (either by window or screen) or it 
could be
queried using the screen/window layout query protocol. Once the screen 
capture
has been set up, a stream of DMA-buf (or shm) should be sent to 
different program
that would record the output to whatever format one wants (stream of png 
or video)
using either sw or hw encoders. Both the first and second case would use 
an external
program to select the output format and encoding method. The good thing 
is that this
encoding program would be compositor-independent and could be shared by 
all of them.
Weston could then get rid of his VA-encoder and just use this new protocol.

The good thing about sending a stream of images is that we get explicit 
synchronization
between the compositor and the screen grabbing app which means it can 
miss no frames
nor sample the same one twice (unless that's what the app wants).

Again, any thoughts on this?

Cheers,
Martin

[1]:
The screenshot "API" could just grab an image based on what hotkey is used:
- window under the cursor
- current screen (where the cursor is)
- all the screens
I'm not sure how to do that on touch devices, but this is a compositor
implementation detail. Once the image is grabbed, the compositor should 
either
save the file somewhere or pass it to an application.