[Bug 28366] Add DBusTube interface support

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=28366

--- Comment #26 from Olli Salli <ollisal at gmail.com> 2011-11-11 06:58:16 PST ---
Thanks, Simon, for the exhaustive reply on the use of credentials passing in
DBus.

(In reply to comment #22)
> TBH, I'm not really getting this part. DBus can indeed choose whether or not to
> require credentials, and the default behavior is yes. Gabble indeed offers the
> possibility of choosing. Changing the default to true seems a good pick to me -
> but I'm not sure if removing the choice makes sense. Or I misunderstood your
> point?
> 

>From Simon's excellent summary, we can conclude that we can sensibly offer the
parameter. Also, as connecting as a different user is seldom useful, we should
indeed change the default to S_A_C_Creds here.

However, as the DBus concept is that of restricting connections to those from a
particular user - and the use of SCM_CREDS on some platforms is just an
implementation detail - we should change the terminology in our public API
accordingly. That would mean changing the parameter to "allowOtherUsers" with
inverted logic, and the capability checker to just "supportsUserAccessControl"
(no ambiguity) or alike. Obviously document the (inverse) relationship between
the two.

We should also document that the choice of using UID access control or allowing
all users must be communicated to the dbus transport used as well.

I expect that in most uses, people would not care at all if such access control
is in use, and use the dbus transport defaults (restrict to single user if
possible but be able to function even if not). Thus we should perhaps change
trying to use the default (enable S_A_C_Creds) when there is no support (e.g.
Windows?) from an hard error to a warning, to match the dbus behavior.

People *really* needing stringent security can either assert (forgoing tubes
support these platforms) or otherwise bail out on their own, by checking the
capability accessor before trying to accept / offer the tube. This matches the
behavior of StreamTubeClient: it doesn't drop tubes on the floor or fail by
itself even for ones that don't support Creds (or Port in the case of TCP), but
allows the user to reject the tube if other local users eavesdropping are a
bigger worry than fulfilling the app's functionality goals.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA Contact for the bug.