Plugin-based auth/transport (WAS: SSH transport)

Daniel P. Berrange dan at berrange.com
Fri Mar 2 06:15:19 PST 2007


On Fri, Mar 02, 2007 at 12:39:32PM +0200, Zeeshan Ali wrote:
> Hello again!
>    Since some people showed their concerns over an ssh-based
> transport, another idea came to my mind: A plugin mechanism for
> authentication and transport: A user/admin be able to tell libbus to
> fetch a auth/tranport impelmentation from a dynamic library file on
> the fly. This way people can write auth/transport implementations of
> their own and if/once their implementations are accepted enough by the
> community, they can be merged into libdbus (which shouldn't take a lot
> of efforts), otherwise those implementations would stay outside dbus
> and everyone would live happily ever after in any case.

If we did provide a plugin system we'd have to be very careful about the
way the concepts of auth & transport were tied together in the API. Some
data transport methods may provide an authentication layer specific to 
their transport (eg SSL provides X509 certs, or SSH provides all sorts), 
but some transports may not provide any auth, while some auth schemes 
can be used with any transport. Also while many transports are socket
based (existing UNIX/TCP ones, SSH, SSL, Layered over X), others may
not be in the future - eg a shared memory transport. So we'd also have
to be careful not to make a plugin API overly restrictive.

> Although i am myself not sure if it's a good idea or not and I got
> mixed opinions from irc channel so I am writing to the ML to get more
> suggestions/opinions/criticism.

To be honest I'm not sure there is a pressing need for a plugin system
in DBus - if OpenSSH had the ability to automatically tunnel forward
existing DBus protocol in the same way it does for X, there'd be no
need for any SSH support in libdbus itself. I could still imagine SSL
being added to libdbus since SSL is a very good protocol for adding
encrypted transports to apps. It is also trivially implemented by C#
and Java native bindings - libssh would be significantly harder for
them since since their standard library runtimes don't provide APIs 
for SSH. I think interoperability between the different DBus protocol
implementations is of key importance. Every new auth/transport scheme
implemented in libdbus will also have to be implemented in the C# and
Java native bindings (which don't use libdbus) - so keeping to a small
well defined set of transports/auth schemes (preferrably using standard
protcols) is very important for maintainity interoperability between
apps.

Regards,
Dan.
-- 
|=-            GPG key: http://www.berrange.com/~dan/gpgkey.txt       -=|
|=-       Perl modules: http://search.cpan.org/~danberr/              -=|
|=-           Projects: http://freshmeat.net/~danielpb/               -=|
|=-   berrange at redhat.com  -  Daniel Berrange  -  dan at berrange.com    -=|
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.freedesktop.org/archives/dbus/attachments/20070302/c1de4d16/attachment.pgp


More information about the dbus mailing list