Bug 30043

After discussions with Simon and Will in which we weren't thrilled about the inverted way this works, but couldn't find a better practical solution, merging this (note that it's in Handler.FUTURE).

Reopening this, since it's not stable API.

We need to come up with some better wording for this before undrafting it. It's not a security feature unless your platform is very specialized (SELinux/Bitfrost levels of strangeness):

- it doesn't prevent looking at NewChannels on the session bus, which
  isn't normally a privilege boundary
- it doesn't prevent D-Bus eavesdropping on the session bus, which
  isn't normally a privilege boundary
- in extreme cases, it doesn't prevent a determined observer from
  ptrace()ing the connection manager, which doesn't usually have a
  privilege boundary between it and the rest of the session!

However, it does prevent MC from waiting for observers to start: an actively malicious observer can still kill, ptrace or otherwise subvert MC or the CM, but it does mean that an observer that's merely buggy can't accidentally delay channel handling.

One possible way to make this flag easier to explain would be to make it imply BypassApproval and an elevated filter-matching "quality" in the dispatcher, which would extend its semantics to something more like "this handler is a control freak". Perhaps "ExclusiveHandler" would be a good name for that feature?

ceci n'est pas un patch

(In reply to comment #3)
> We need to come up with some better wording for this before undrafting it. It's
> not a security feature unless your platform is very specialized
> (SELinux/Bitfrost levels of strangeness)

This still stands.

> One possible way to make this flag easier to explain would be to make it imply
> BypassApproval and an elevated filter-matching "quality" in the dispatcher,
> which would extend its semantics to something more like "this handler is a
> control freak".

I still think this would be a better set of semantics - it would probably make the desired implementation in Bug #40283 more obvious, too.

(In reply to comment #5)
> (In reply to comment #3)
> > We need to come up with some better wording for this before undrafting it. It's
> > not a security feature unless your platform is very specialized
> > (SELinux/Bitfrost levels of strangeness)
> 
> This still stands.
> 
> > One possible way to make this flag easier to explain would be to make it imply
> > BypassApproval and an elevated filter-matching "quality" in the dispatcher,
> > which would extend its semantics to something more like "this handler is a
> > control freak".
> 
> I still think this would be a better set of semantics - it would probably make
> the desired implementation in Bug #40283 more obvious, too.

Yep, I basically agree with that. Broadly speaking, the goal here would be to have a dedicated UI for a particular account, without having to eschew the benefits of using MC and friends, or have to patch MC and the CM: you could just have a handler which matches channels for that account (cf. bug 30963).

We could conceivably back the implementation out of MC, given that it doesn't work that well by all accounts.

(In reply to comment #6)
> We could conceivably back the implementation out of MC, given that it
> doesn't work that well by all accounts.

I think I'm going to do that, at least for 1.0. We can bring it back when someone has a use-case and a better implementation.

Created attachment 88642 [details] [review]
Remove BypassObservers support

It wasn't implemented correctly (see bug #40305) and I wasn't convinced
by the design (see bug #30043). Let's think about it more before we
bring it back.

Comment on attachment 88642 [details] [review]
Remove BypassObservers support

Review of attachment 88642 [details] [review]:
-----------------------------------------------------------------

Agreed let's drop this thing. ++

Interface deleted. RESOLVED WONTFIX until someone comes back with a concrete use-case and a better implementation.