Re: Collaboration on standard Wayland protocol extensions

Hello Drew, After reading the thread stream, I think there is two mixed questions in your email that is missleading. And most reply try to address both in one reply. I thing Daniel get the point (if I understood him well). I read the two following questions: [1] As almost all compositor will

Re: Collaboration on standard Wayland protocol extensions

On 29/03/16 13:11, Drew DeVault wrote: > I see what you're getting at now. We can get the pid of a wayland > client, though, and from that we can look at /proc/cmdline, from which > we can get the binary path. This line of thinking is a trap: rummaging in /proc/$pid is not suitable for use as a

Re: Collaboration on standard Wayland protocol extensions

Hi, On 31 March 2016 at 00:16, Drew DeVault wrote: > Simply because xrandr was/is a poorly implemented mess doesn't mean that > we are going to end up making a poorly implemented mess. We have the > benefit of hindsight. After all, xorg is a poorly implemented mess but > we still

Re: Collaboration on standard Wayland protocol extensions

Simply because xrandr was/is a poorly implemented mess doesn't mean that we are going to end up making a poorly implemented mess. We have the benefit of hindsight. After all, xorg is a poorly implemented mess but we still made Wayland, didn't we? (Though some could argue that we've just ended up

Re: Collaboration on standard Wayland protocol extensions

On Tue, Mar 29, 2016 at 5:24 AM, Drew DeVault wrote: >> Thirdly, it's important to take a step back. 'Wayland doesn't support >> middle-button primary selections' is a feature gap compared to X11; >> 'Wayland doesn't have XRandR' is not. Sometimes it seems like you miss >> the

Re: Collaboration on standard Wayland protocol extensions

On 30/03/16 09:33, Jasper St. Pierre wrote: I really hope that distributions don't see security policies as a differentiator. This is how we got SELinux vs. AppArmor and real-world apps having to ship both kinds of policies (or Fedora flat out ignoring any idea of third-parties and such and

Re: Collaboration on standard Wayland protocol extensions

I really hope that distributions don't see security policies as a differentiator. This is how we got SELinux vs. AppArmor and real-world apps having to ship both kinds of policies (or Fedora flat out ignoring any idea of third-parties and such and including literally every application ever in its

Re: Collaboration on standard Wayland protocol extensions

On 30/03/16 01:12, Olav Vitters wrote: On Mon, Mar 28, 2016 at 10:50:23PM +0300, Martin Peres wrote: We thus wanted to let distros take care of most of the policies (which does not amount to much and will likely come with the application anyway). However, some distros or devices come with a

Re: Collaboration on standard Wayland protocol extensions

On Tuesday, March 29, 2016 8:14:25 AM CEST Drew DeVault wrote: > On 2016-03-29 10:25 AM, Martin Graesslin wrote: > > > - More detailed surface roles (should it be floating, is it a modal, > > > > > > does it want to draw its own decorations, etc) > > > > Concerning own decoration we have

Re: Collaboration on standard Wayland protocol extensions

On Tuesday, March 29, 2016 8:12:32 AM CEST Drew DeVault wrote: > On 2016-03-29 10:20 AM, Martin Graesslin wrote: > > > - Output configuration > > > > we have our kwin-kscreen specific protocol for this. You can find it at: > > https://quickgit.kde.org/? > >

Re: Collaboration on standard Wayland protocol extensions

On Tue, 29 Mar 2016 08:11:03 -0400 Drew DeVault said: > > what is allowed. eg - a whitelist of binary paths. i see this as a lesser > > chance of a hole. > > I see what you're getting at now. We can get the pid of a wayland > client, though, and from that we can look at

Re: Collaboration on standard Wayland protocol extensions

On Mon, Mar 28, 2016 at 10:50:23PM +0300, Martin Peres wrote: > We thus wanted to let distros take care of most of the policies (which > does not amount to much and will likely come with the application > anyway). However, some distros or devices come with a system > that already defines security

Re: Collaboration on standard Wayland protocol extensions

On 27/03/16 23:34, Drew DeVault wrote: Greetings! I am the maintainer of the Sway Wayland compositor. http://swaywm.org It's almost the Year of Wayland on the Desktop(tm), and I have reached out to each of the projects this message is addressed to (GNOME, Kwin, and wayland-devel) to

Re: Collaboration on standard Wayland protocol extensions

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

Re: Collaboration on standard Wayland protocol extensions

On Mon, 28 Mar 2016 10:55:05 -0400 Drew DeVault said: > On 2016-03-28 11:03 PM, Carsten Haitzler wrote: > > should we? is it right to create yet another rsecurity model in userspace > > "quickly" just to solve things that dont NEED solving at least at this > > point. > > I don't

Re: Collaboration on standard Wayland protocol extensions

On Sun, 27 Mar 2016 16:34:37 -0400 Drew DeVault said: > Greetings! I am the maintainer of the Sway Wayland compositor. > > http://swaywm.org > > It's almost the Year of Wayland on the Desktop(tm), and I have > reached out to each of the projects this message is addressed to

Re: Collaboration on standard Wayland protocol extensions

On Sun, 27 Mar 2016 22:29:57 -0400 Drew DeVault said: > On 2016-03-28 8:55 AM, Carsten Haitzler wrote: > > i can tell you that screen capture is a security sensitive thing and likely > > won't get a regular wayland protocol. it definitely won't from e. if you can > > capture

Re: Collaboration on standard Wayland protocol extensions

On Mon, 28 Mar 2016 09:00:34 -0400 Drew DeVault said: > On 2016-03-28 2:13 PM, Carsten Haitzler wrote: > > yes but you need permission and that is handled at kernel level on a > > specific file. not so here. compositor runs as a specific user and so you > > cant do that. you'd

Re: Collaboration on standard Wayland protocol extensions

2016-03-27 23:34 GMT+03:00 Drew DeVault : > Greetings! I am the maintainer of the Sway Wayland compositor. > > http://swaywm.org > > It's almost the Year of Wayland on the Desktop(tm), and I have > reached out to each of the projects this message is addressed to (GNOME, > Kwin, and

Re: Collaboration on standard Wayland protocol extensions

On Tue, 29 Mar 2016 08:25:19 +0300 Giulio Camuffo wrote: > 2016-03-29 6:23 GMT+03:00 Drew DeVault : > > On 2016-03-29 2:15 AM, Martin Peres wrote: > >> I was proposing for applications to just bind the interface and see if it > >> works or not. But

Re: Collaboration on standard Wayland protocol extensions

On Tue, 29 Mar 2016 12:01:52 +0800 Jonas Ådahl wrote: > On Mon, Mar 28, 2016 at 11:33:15PM -0400, Drew DeVault wrote: > > On 2016-03-29 10:30 AM, Jonas Ådahl wrote: > > > I'm just going to put down my own personal thoughts on these. I mostly > > > agree with Carsten on all of

Re: Collaboration on standard Wayland protocol extensions

On Sunday, March 27, 2016 4:34:37 PM CEST Drew DeVault wrote: > Greetings! I am the maintainer of the Sway Wayland compositor. > > http://swaywm.org > > It's almost the Year of Wayland on the Desktop(tm), and I have > reached out to each of the projects this message is addressed to (GNOME, >

Re: Collaboration on standard Wayland protocol extensions

On Tue, 29 Mar 2016 07:41:10 -0400 Drew DeVault wrote: > Thus begins my long morning of writing emails: > > On 2016-03-29 12:01 PM, Jonas Ådahl wrote: > Not everyone has dbus on their system and it's not among my goals to > force it on people. I'm not taking a political stance

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

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

Re: Collaboration on standard Wayland protocol extensions

On Mon, 28 Mar 2016 09:08:55 +0300 Giulio Camuffo wrote: > 2016-03-27 23:34 GMT+03:00 Drew DeVault : > > Greetings! I am the maintainer of the Sway Wayland compositor. > > > > http://swaywm.org > > > > It's almost the Year of Wayland on the Desktop(tm),

Re: Collaboration on standard Wayland protocol extensions

On Tue, 29 Mar 2016 08:11:03 -0400 Drew DeVault wrote: > On 2016-03-29 3:10 PM, Carsten Haitzler wrote: > > > 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 > > > > why? > >

Re: Collaboration on standard Wayland protocol extensions

2016-03-29 6:23 GMT+03:00 Drew DeVault : > On 2016-03-29 2:15 AM, Martin Peres wrote: >> I was proposing for applications to just bind the interface and see if it >> works or not. But Giulio's proposal makes sense because it could be used to >> both grant and revoke rights on the

Re: Collaboration on standard Wayland protocol extensions

On 28/03/16 23:47, Drew DeVault wrote: On 2016-03-28 10:50 PM, Martin Peres wrote: Client->Server: What features do you support? Server->Client: These privledged features are available. Client->Server: I want this feature (nonblocking) [compositor prompts user to agree] Server->Client: Yes/no

Re: Collaboration on standard Wayland protocol extensions

On 28/03/16 16:04, Drew DeVault wrote: On 2016-03-28 9:08 AM, Giulio Camuffo wrote: On this, see https://lists.freedesktop.org/archives/wayland-devel/2015-November/025734.html I have not been able to continue on that, but if you want to feel free to grab that proposal. I looked through this

Re: Collaboration on standard Wayland protocol extensions

On 28/03/16 02:41, Jasper St. Pierre wrote: You're probably referring to my response when you say "GNOME does not care about cross-platform apps doing privileged operations". My response wasn't meant to be speaking on behalf of GNOME. These are my opinions and mine alone. I must have

Re: Collaboration on standard Wayland protocol extensions

Hi, On 29 March 2016 at 13:24, Drew DeVault wrote: > On 2016-03-29 11:45 AM, Daniel Stone wrote: >> Firstly, >> https://www.redhat.com/archives/fedora-devel-list/2008-January/msg00861.html >> is a cliché, but the spirit of free software is empowering people to >> make the change

Re: Collaboration on standard Wayland protocol extensions

On 2016-03-29 11:45 AM, Daniel Stone wrote: > Firstly, > https://www.redhat.com/archives/fedora-devel-list/2008-January/msg00861.html > is a cliché, but the spirit of free software is empowering people to > make the change they want to see, rather than requiring the entire > world be perfectly

Re: Collaboration on standard Wayland protocol extensions

On Tue, Mar 29, 2016 at 07:41:10AM -0400, Drew DeVault wrote: > Thus begins my long morning of writing emails: > > On 2016-03-29 12:01 PM, Jonas Ådahl wrote: > > > I prefer to think of it as "who has logical ownership over this resource > > > that they're providing". The compositor has ownership

Re: Collaboration on standard Wayland protocol extensions

Hi, On 29 March 2016 at 13:11, Drew DeVault wrote: >> or just have the compositor "work" without needing scripts and users to have >> to >> learn how to write them. :) > > Never gonna happen, man. There's no way you can foresee and code for > everyone's needs. I'm catching on to

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

This a mistake on my part. I mixed up the two protocols, I don't intend to make any changes to fullscreen-shell. Sorry for the confusion. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org

Re: Collaboration on standard Wayland protocol extensions

On 2016-03-29 10:25 AM, Martin Graesslin wrote: > > - More detailed surface roles (should it be floating, is it a modal, > > does it want to draw its own decorations, etc) > > Concerning own decoration we have implemented https://quickgit.kde.org/? >

Re: Collaboration on standard Wayland protocol extensions

On 2016-03-29 10:20 AM, Martin Graesslin wrote: > > - Output configuration > > we have our kwin-kscreen specific protocol for this. You can find it at: > https://quickgit.kde.org/? > p=kwayland.git=blob=9ebe342f7939b6dec45e2ebf3ad69e772ec66543=818e320bd99867ea9c831edfb68c9671ef7dfc47=src >

Re: Collaboration on standard Wayland protocol extensions

On 2016-03-29 3:10 PM, Carsten Haitzler wrote: > > 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 > > why? > > there is no way a process can access the socket with privs (even know the > extra

Re: Collaboration on standard Wayland protocol extensions

On 2016-03-29 8:25 AM, Giulio Camuffo wrote: > If the client just binds the interface the compositor needs to > immediately create the resource and send the protocol error, if the > client is not authorized. It doesn't have the time to ask the user for > input on the matter, while my proposal

Re: Collaboration on standard Wayland protocol extensions

Thus begins my long morning of writing emails: On 2016-03-29 12:01 PM, Jonas Ådahl wrote: > > I prefer to think of it as "who has logical ownership over this resource > > that they're providing". The compositor has ownership of your output and > > input devices and so on, and it should be

Re: Collaboration on standard Wayland protocol extensions

Hi, On 29 March 2016 at 05:01, Drew DeVault wrote: > You don't provide any justification for this, you just say it like it's > gospel, and it's not. I will again remind you that not everyone wants to > buy into a desktop environment wholesale. They may want to piece it > together

Re: Collaboration on standard Wayland protocol extensions

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

Re: Collaboration on standard Wayland protocol extensions

On Mon, Mar 28, 2016 at 11:33:15PM -0400, Drew DeVault wrote: > On 2016-03-29 10:30 AM, Jonas Ådahl wrote: > > I'm just going to put down my own personal thoughts on these. I mostly > > agree with Carsten on all of this. In general, my opinion is that it is > > completely pointless to add Wayland

Re: Collaboration on standard Wayland protocol extensions

On 2016-03-29 10:30 AM, Jonas Ådahl wrote: > I'm just going to put down my own personal thoughts on these. I mostly > agree with Carsten on all of this. In general, my opinion is that it is > completely pointless to add Wayland protocols for things that has > nothing to do with Wayland what so

Re: Collaboration on standard Wayland protocol extensions

On 2016-03-29 2:15 AM, Martin Peres wrote: > I was proposing for applications to just bind the interface and see if it > works or not. But Giulio's proposal makes sense because it could be used to > both grant and revoke rights on the fly. I think both solutions have similar merit and I don't

Re: Collaboration on standard Wayland protocol extensions

On Sun, Mar 27, 2016 at 04:34:37PM -0400, Drew DeVault wrote: > Greetings! I am the maintainer of the Sway Wayland compositor. > > http://swaywm.org > > It's almost the Year of Wayland on the Desktop(tm), and I have > reached out to each of the projects this message is addressed to (GNOME, >

Re: Collaboration on standard Wayland protocol extensions

On Sun, Mar 27, 2016 at 04:34:37PM -0400, Drew DeVault wrote: > Greetings! I am the maintainer of the Sway Wayland compositor. > > http://swaywm.org > > It's almost the Year of Wayland on the Desktop(tm), and I have > reached out to each of the projects this message is addressed to (GNOME, >

Re: Collaboration on standard Wayland protocol extensions

On 2016-03-28 4:35 PM, Emmanuele Bassi wrote: > If you want to add additional stuff on top of a live stream, use > something with a programmable pipeline that can add effects to the > stream coming from the compositor. Why do we need negotiation, or user > interation, or exchange of metadata for

Re: Collaboration on standard Wayland protocol extensions

Hi; On 28 March 2016 at 15:55, Drew DeVault wrote: > You're still not grasping the scope of this. I want you to run this > command right now: > > man ffmpeg-all > > Just read it for a while. You're delusional if you think you can > feasibly implement all of these features in the

Re: Collaboration on standard Wayland protocol extensions

On 2016-03-28 11:03 PM, Carsten Haitzler wrote: > should we? is it right to create yet another rsecurity model in userspace > "quickly" just to solve things that dont NEED solving at least at this point. I don't think that the protocol proposed in other branches of this thread is complex or short

Re: Collaboration on standard Wayland protocol extensions

On 2016-03-28 9:08 AM, Giulio Camuffo wrote: > On this, see > https://lists.freedesktop.org/archives/wayland-devel/2015-November/025734.html > I have not been able to continue on that, but if you want to feel free > to grab that proposal. I looked through this protocol and it seems like it's a

Re: Collaboration on standard Wayland protocol extensions

On 2016-03-27 10:21 PM, Jasper St. Pierre wrote: > I would rather the effort be spent making secure interfaces, exactly > as you've described. Agreed. I think it should be pretty straightforward: Client->Server: What features do you support? Server->Client: These privledged features are

Re: Collaboration on standard Wayland protocol extensions

On 2016-03-28 2:13 PM, Carsten Haitzler wrote: > yes but you need permission and that is handled at kernel level on a specific > file. not so here. compositor runs as a specific user and so you cant do that. > you'd have to do in-compositor security client-by-client. It is different, but we

Re: Collaboration on standard Wayland protocol extensions

On Sun, Mar 27, 2016 at 7:33 PM, Drew DeVault wrote: > On 2016-03-27 4:41 PM, Jasper St. Pierre wrote: > > What are your specific concerns with it? I would tend to agree. I think > that it's not bad as an implementation of this mechanic, but I agree > that it's approaching the

Re: Collaboration on standard Wayland protocol extensions

On 2016-03-27 4:41 PM, Jasper St. Pierre wrote: > My opinion is still as follows: having seen how SELinux and PAM work > out in practice, I'm skeptical of any "Security Module" which > implements policy. The "module" part of it rarely happens, since > people simply gravitate towards a standard

Re: Collaboration on standard Wayland protocol extensions

On 2016-03-28 8:55 AM, Carsten Haitzler wrote: > i can tell you that screen capture is a security sensitive thing and likely > won't get a regular wayland protocol. it definitely won't from e. if you can > capture screen, you can screenscrape. some untrusted game you downloaded for > free can

Re: Collaboration on standard Wayland protocol extensions

You're probably referring to my response when you say "GNOME does not care about cross-platform apps doing privileged operations". My response wasn't meant to be speaking on behalf of GNOME. These are my opinions and mine alone. My opinion is still as follows: having seen how SELinux and PAM work

Re: Collaboration on standard Wayland protocol extensions

Thanks for the links! I'll read through them. I figured that a discussion like this had happened in the past around how to give clients privledge, but I couldn't find anything that would allow them to actually do the thing they were given permission to. We should flesh out both parts of this

Collaboration on standard Wayland protocol extensions

Greetings! I am the maintainer of the Sway Wayland compositor. http://swaywm.org It's almost the Year of Wayland on the Desktop(tm), and I have reached out to each of the projects this message is addressed to (GNOME, Kwin, and wayland-devel) to collaborate on some shared protocol extensions for