fullscreen shell is irrelevant to this (Re: Collaboration on standard Wayland protocol extensions)

[Pekka Paalanen]

On Tue, 29 Mar 2016 00:01:00 -0400
Drew DeVault <sir at cmpwn.com> wrote:

> On 2016-03-29 11:31 AM, Carsten Haitzler wrote:
> > my take on it is that it's premature and not needed at this point. in fact i
> > wouldn't implement a protocol at all. *IF* i were to allow special access, i'd
> > simply require to fork the process directly from compositor and provide a
> > socketpair fd to this process and THAT fd could have extra capabilities
> > attached to the wl protocol. i would do nothing else because as a compositor i
> > cannot be sure what i am executing. i'd hand over the choice of being able to
> > execute this tool to the user to say ok to and not just blindly execute
> > anything i like.  
> 
> I don't really understand why forking from the compositor and bringing
> along the fds really gives you much of a gain in terms of security. Can
> you elaborate on how this changes things? I should also mention that I
> don't really see the sort of security goals Wayland has in mind as
> attainable until we start doing things like containerizing applications,
> in which case we can elimitate entire classes of problems from this
> design.

> I'm snipping out a lot of the output configuration related stuff from
> this response. I'm not going to argue very hard for a common output
> configuration protocol. I've been trying to change gears on the output
> discussion towards a discussion around whether or not the
> fullscreen-shell protocol supports our needs and whether or how it needs
> to be updated wrt permissions.

I sense there is a misunderstanding here, that I want to correct.

The fullscreen-shell protocol is completely irrelevant here. It has
been designed to be mutually exclusive to a desktop protocol suite.

The original goal for the fullscreen-shell is to be able to use a
ready-made compositor, e.g. Weston in particular, as a hardware
abstraction layer for a single application. We of course have some demo
programs to use it so we can test it.

That single application would often be a DE compositor, perhaps a small
project which does not want to deal with all the KMS and other APIs but
concentrate on making a good DE at the expense of the slight overhead
that using a middle-man compositor brings.

Now that we have decided that libweston is a good idea, I would assume
this use case may disappear eventually.

There are also no permission issues wrt. to the fullscreen shell
protocol. The compositor exposing the fullscreen shell interface expects
only a single client ever, or works a bit like the VTs in that only a
single client can be active at a time. Ordinarily you set up the
application such, that the parent compositor is launched as part of the
app launch, and nothing else can even connect to the parent compositor.

Fullscreening windows on a desktop has absolutely nothing to do with
the fullscreen shell. Fullscreen shell is not available on compositors
configured for desktop. This is how it was designed and meant to be.


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 811 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20160329/3fdd6c32/attachment.sig>