winDBus authentication stage

[Peter Kümmel]

Havoc Pennington wrote:
> 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.
> 

I thought all non unix files are platform-independent, therefore the hack.

> 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
> _______________________________________________
> dbus mailing list
> dbus at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dbus
> 


-- 
Peter Kümmel