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 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
Attachment:
pgpYYECJNaTR1.pgp
Description: OpenPGP digital signature