winDBus authentication stage

[Havoc Pennington]

Ralf Habacker wrote:
>>> 2) The EXTERNAL authentication mechanism used on the winDBus tcp
>>> transport seems to require a global atom representing the user SID as
>>> a string (where the unix uid would usually be as a string). What is
>>> the the reasoning behind this?
> There was an ongoing discussion that windows dbus should does have a
> different authentification scheme because user id's are not available on
> windows. Havoc can say more to this item.

It just happens because of the hack used to implement dbus_uid_t on 
Windows; the dbus_uid_t is an atom, and nobody changed the part of the 
code that converts to a string for auth to do the right thing on windows 
and convert to an sid string instead of a number. There's also a leak 
problem where there's no reliable way to GlobalDeleteAtom, afaict. This 
hack should not be escaping over the wire, as has been discussed to death.

All that's really needed, I would guess, is to abstract the 
uid-to-string operation so dbus_append_uid() is used instead of 
dbus_string_append_uint(). There is already a dbus_parse_uid 
abstraction. At that point the need to globally register atoms should go 
away also, along with the question of when to globally delete them.

>> windbus is still totally busted afaik. 
> Do you ever tried windbus ?

I've seen the code, which clearly needs fixing in many places, as I've 
pointed out as the patches are submitted. The fact that it runs in some 
situations is not relevant at all as far as I'm concerned.

Problems like the ones Alp reported are caused by the stuff I'm asking 
to be fixed; inappropriate unix emulation and #ifdef'ing.

>> Both 1) and 2) are bugs.
> 1) yes
> 2) design isn't finished, what to send over the wire for windows.

What is the normal string representation of a user on windows? I would 
predict an sid string. So why not send that.

>> I would not bother trying to support dbus on win32 until we get it
>> integrated into the dbus mainline.
> Why not - the more developers are using the current code, the more input
> comes  and integration into dbus-cvs would be nearer in the future.

Helping out on windbus testing I would certainly encourage. What I meant 
is, the protocol (e.g. uid to send for auth) and behavior (e.g. how the 
bus is located and launched) are in flux for now.

Havoc