Bug 30043 - A way for channel handlers to request observer bypassing
Summary: A way for channel handlers to request observer bypassing
Status: RESOLVED WONTFIX
Alias: None
Product: Telepathy
Classification: Unclassified
Component: tp-spec (show other bugs)
Version: unspecified
Hardware: Other All
: medium enhancement
Assignee: Simon McVittie
QA Contact: Telepathy bugs list
URL:
Whiteboard: patch to remove
Keywords: patch
Depends on: 40283 40305
Blocks:
  Show dependency treegraph
 
Reported: 2010-09-06 05:55 UTC by Senko Rasic
Modified: 2014-01-07 17:48 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
Remove BypassObservers support (19.51 KB, patch)
2013-11-04 18:48 UTC, Simon McVittie
Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Senko Rasic 2010-09-06 05:55:58 UTC
It would be useful if a handler could specify channels which shouldn't be observed - eg. for "secret" channels that should not be logged. We could add a BypassObservers property to the Handler for this.

Git branch:
http://git.collabora.co.uk/?p=user/ptlo/tp-spec-senko/.git;a=shortlog;h=refs/heads/bypass-observer

HTML docs:
http://people.freedesktop.org/~senko/telepathy-spec-bypass_observer/spec/Client_Handler_Future.html
Comment 1 Senko Rasic 2010-10-12 05:40:14 UTC
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).
Comment 2 Simon McVittie 2010-10-15 04:33:26 UTC
Reopening this, since it's not stable API.
Comment 3 Simon McVittie 2010-10-15 04:51:39 UTC
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?
Comment 4 Simon McVittie 2010-10-25 10:09:23 UTC
ceci n'est pas un patch
Comment 5 Simon McVittie 2011-08-23 05:06:04 UTC
(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.
Comment 6 Will Thompson 2011-09-20 06:00:42 UTC
(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.
Comment 7 Simon McVittie 2013-11-04 17:56:54 UTC
(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.
Comment 8 Simon McVittie 2013-11-04 18:48:05 UTC
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 9 Guillaume Desmottes 2014-01-07 15:47:24 UTC
Comment on attachment 88642 [details] [review]
Remove BypassObservers support

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

Agreed let's drop this thing. ++
Comment 10 Simon McVittie 2014-01-07 17:48:45 UTC
Interface deleted. RESOLVED WONTFIX until someone comes back with a concrete use-case and a better implementation.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.