Integrating Cyrus SASL

[Ryan Saunders]

> The problem remains that apps won't implement those interactivity
> hooks reliably. I don't have an objection to adding them; I would wrap
> them in a nice libdbus-looking API though. But it will be years (at
> best) before you could really use an interactive auth mechanism with a
> generic desktop app and expect it to work.

Yeah, I agree that I/we would need to implement default interactivity in order to expect arbitrary apps to work properly, since an "everybody, please go implement this" policy would take forever. I wonder if there's a way to have the core Gnome and KDE libs implement a GUI solution for this, which their apps would "inherit" simply by using the Gnome or KDE framework...something that lives in libkdecore4.so, for example. It would be neat if something like that could be made to work, because it would mean that all [Gnome| | KDE] apps would work out of the box (and, furthermore, the UI that the user sees would be consistent with the rest of the desktop UI).

You make a good point regarding caching the credentials...if we don't do at least _some_ caching, the user would go nuts constantly entering his password. Caching credentials across multiple processes could be a tad tricky, since dbus itself cannot be the mechanism used to access the shared cache (the chicken/egg problem we've been discussing). I suppose the "default" interactivity implementation I mentioned earlier might reasonably connect to a [Gnome | KDE] process listening on a UNIX socket, or something, in order to access the credential cache...though I don't know how secure that approach is.

In any case, to start with at least, I think it's OK if we only cache credentials at the process level, rather than trying to do it per-session. Here's why. The current, typical deployment of DBus, where the session bus lives on the same machine as the user's login, and EXTERNAL auth is used to authenticate apps connecting to the bus...this seems to be working just fine. I can't really think of a compelling scenario where the user would want to re-point his entire login session to use a session bus on another machine...it seems to me that this might not work for other reasons, largely unrelated to DBus itself. Rather, the major usage scenario for alternative auth schemes, it seems to me, is to re-point a _specific_ app to a session bus on a remote machine, in order to manipulate it remotely (e.g., to control a media player on a remote machine, as I'm trying to do). In this case, the session bus will be listening on multiple sockets (i.e., a UNIX socket
 and a TCP socket), and only remote client apps will be using the secondary TCP socket (all local apps would still use EXTERNAL auth). In order to make an app connect to a remote session bus, the user needs to manually re-point it, by setting DBUS_SESSION_BUS_ADDRESS, and it seems unlikely that the user will be doing this for lots and lots of separate processes. Of course, I could be wrong, in which case, someone will eventually get sufficiently fed up with it to implement a better strategy. :-)

R