dbus-sysdeps-unix.h

[Havoc Pennington]

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 
connections.

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 
set_unix_user_function().

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:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnanchor/html/securityanchor.asp

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:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnucmg/html/ucmglp.asp

It looks to me like an SID structure might be what the Windows 
equivalent of "unix user function" should take?
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/secauthz/security/sid.asp

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.

Havoc