winDBus authentication stage

[Ralf Habacker]

Havoc Pennington schrieb:
> 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. 
Hmmh, using dbus_uid_t was your proposal see
http://lists.freedesktop.org/archives/dbus/2006-June/005043.html
> 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.
No idea why this goes wrong. Have you any pointer in the list  ?
>
> 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.
no, the first problem was there because noone has tested before the
interoperability of windbus. It was simple not implemented, but
fortunally a patch is on the way :-)

>
>>> 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 will need some research, which would be the best form or does someone
else could give here a hint ?

>>> 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.
yes testing in relation to the win32 port needs a unix counterpart,
because there may be things broken on both sides like the last
_dbus_pipe commit. ;-)

Ralf