hp at redhat.com
Sun Sep 17 10:06:37 PDT 2006
Peter Kümmel wrote:
> Thanks for the api changes; it's much faster when you change it directly
> than waiting for the patches of a whining windows guy. ;)
> I've updated our svn repository, but now we get an regression in the bus test.
> Have you changed the error handling?
I haven't, but as I said I made the _unix functions on DBusConnection
only work on unix. If you run the bus tests with verbose logging then I
think you'll find it's upset that it can't get the unix user for the
You'll probably need to add the equivalent of
connection_set_unix_user_function and connection_get_unix_user for
Windows, then use those in the bus.
There may be other issues also, but I'm pretty sure this will be an issue.
The simple fix: I bet we don't care about the "system bus" on Windows.
That means we only care about a bus running in the user's session and
that bus needs to allow the same user to connect while denying all other
users. Thus, all you have to do is find a way to authenticate that a
connecting client is owned by the same user as the bus. There's no need
for the rest of the user-related configuration to work as it does on
unix. On Windows, user-based security policy matching in the config file
could just be disallowed for now (ideally, trying to use an unsupported
option results in an error message).
If you do it this way, you won't even need the equivalent of
Come to think of it if you had this working already I probably broke it
with my dbus-transport.c change. I'll fix that quickly now though I'm
not sure it will fully fix the bus.
If you do want the security policy stuff as found on UNIX, the first
question is what should that be like on Windows. I think it should
probably use the normal Windows authorization / acl mechanism, no?
This looks potentially relevant (see Authorization) though maybe it isn't:
This is maybe even more useful, see Chapter 6 "UNIX and Windows
Interoperability" scroll down to the authorization and authentication
section. Also see Chapter 9 "Win32 Code Conversion" which has a bunch of
stuff on how to port unix user stuff to Windows:
It looks to me like an SID structure might be what the Windows
equivalent of "unix user function" should take?
The auth protocol currently sends a unix uid over the wire. What are you
sending for this on Windows? I thought you were using some
process-specific made-up number for dbus_uid_t? Anyway, my wild guess
from skimming msdn docs is that this should probably be a username and
then on successful auth the daemon would do something to "log in" as
that username and get an sid. I don't know though.
In the session bus case, normally no uid is sent over the wire because
the uid is implicit in the socket credentials. So possibly you've just
been using that codepath on Windows.
This part of the auth protocol is definitely unix-specific at the moment
though. I think making parse_uid just barf on Windows might be right,
because anytime a uid is sent between processes, it does not mean
anything on Windows.
More information about the dbus