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

On Tue, 29 Mar 2016 00:01:00 -0400
Drew DeVault <sir 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

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.


Attachment: pgpYYECJNaTR1.pgp
Description: OpenPGP digital signature

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]