dbus-sysdeps-unix.h

[Ralf Habacker]

Havoc Pennington schrieb:
> 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.
Seems not, we got the following error messages

...
bin\bus-test.exe: Running SHA1 connection test
NetUserGetInfo() failed: no valid user_info
Using your real home directory for testing, set DBUS_TEST_HOMEDIR to avoid
check_hello_message:837 received message interface "(unset)" member 
"(unset)" error name "org.freedesktop.DBus.Error.Fai
led" on 009E1050, expecting not this error
File "F:\daten\windbus\trunk\bus\dispatch.c" line 4054 process 740 
should not have been reached: hello message failed
This application has requested the Runtime to terminate it in an unusual 
way.
Please contact the application's support team for more information.

DBUS_VERBOSE=1 gives the following error message:

2284: Name :1.0 assigned to 003D9368
2284:   LOCK: dbus_connection_get_is_authenticated
2284:   UNLOCK: dbus_connection_get_is_authenticated
2284: Appending rule 003D9CE0 with type 0 to policy 009E1CA8
2284: Appending rule 009E5278 with type 1 to policy 009E1CA8
2284: Appending rule 009E1A50 with type 2 to policy 009E1CA8
2284: Failed to create security policy for connection 003D9368
2284: Driver handler returned failure
2284:   LOCK: dbus_connection_get_is_connected
2284:   UNLOCK: dbus_connection_get_is_connected
2284: Sending error reply org.freedesktop.DBus.Error.Failed "No user ID 
known for connection, cannot determine security policy
"
2284: Sending (no interface) (no member) 
org.freedesktop.DBus.Error.Failed from driver
2284:   LOCK: dbus_connection_get_data

Any idea ?

> 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.
>
The current implementation takes windows sid's, which are converted to 
unix like uid_t  type for authentification see _dbus_win_sid_to_uid_t in

 http://svn.sourceforge.net/viewvc/windbus/trunk/dbus/dbus-sysdeps-win.c?revision=318&view=markup

2284: _dbus_win_sid_to_uid_t sid 
S-1-5-21-117666728-374750965-3721689867-1006 added with uid 49203 to cache
2284: _dbus_getuid() returns 49203

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

Ralf