Collaboration on standard Wayland protocol extensions

[Drew DeVault]

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 policy. What's interesting
> to me isn't a piece of code that allows or rejects operations, it's
> the resulting UI *around* those operations and managing them, since
> that's really, at the end of the day, all the user cares about.

It has been done successfully, though. Consider the experience for iOS
and Android permissions. When an application needs to do something
sensitive, a simple dialog pops up explaining what it's asking for, and
allowing the user to consent once or forever. It's pretty simple and I
think we can accomplish something similar.

> It would be a significant failure to me if we didn't have a standard
> way for a user to examine or recall the policy of an application,
> using whatever API they wanted. If every module implements its own
> policy store separately, such a UI would be extremely difficult to
> build.

Ah, but here we are, all talking about it together. Let's make a
solution that works for all of us, then.

> From what I read, Wayland Security Modules didn't seem to even provide
> that as a baseline, which is why I believe they're tackling the
> problem from the wrong angle.

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 problem wrong. I think it would be wiser to
start with how clients ask the compositor for permissions and how they
receive them, then leave the details libwsm implements up to the
compositors.

I think a protocol extension would work just fine to implement a
permission requesting/granting dialogue between clients and compositors.

--
Drew DeVault