win32 dbus_connection_get_unix_user() problem

[Havoc Pennington]

Hi,

Ralf Habacker wrote:
> There are 58 places in dbus code where this dbus_uid_t is used.
> Following your hint means to implement in every of this 55 places a
> different implementation for win32 (string) and unix (int).

You can use the hack where we make up a dbus_uid_t on Windows 
*internally*. But no *application* using libdbus cares about "a random 
integer used to look up an SID in a libdbus-internal hash table." It 
does not make any sense to let this leak out of libdbus. It has no 
meaning outside of the process that created the hash.

Because the bus daemon uses only public libdbus API, it can't use the 
magic internal hash value either.

Again, no unix-emulation hacks are allowed in the public API or config 
files. The public stuff must contain only things that make sense on 
Windows, done in a Windows-native-looking way. Yes, this is harder. It 
is also necessary before we can freeze the API on Windows and have a 
maintainable and sane codebase.

> The following functions uses  dbus_connection_get_unix_user():
> 
> bus_policy_create_client_policy
> bus_connection_disconnected
> bus_connection_get_groups
> bus_connection_complete
> bus_connections_check_limits
> 
> These functions are core dbus function and cannot be skipped.

On Windows, the policy rules that use guid and uid do not make sense. 
So where these functions are using guid/uid, the code does not apply to 
Windows.

On Windows, the config file will need to contain usernames or sids. (Or, 
as a starting point, because the system bus makes no sense on Windows 
anyway - you can just make it an error if the config file contains 
user=""/group="" on Windows.)

> Replacing
> the calls by windows related functions will blow up the code with
> several #ifdef DBUS_WIN ... wrappers.

You should not need to #ifdef DBUS_WIN. Have parse_windows_user that 
always fails on UNIX and returns an sid string. Have a parse_unix_user 
that always fails on Windows and returns a uid. For the user="" 
attribute, call both. In the BusPolicy simply have two different fields, 
one for sid and one for uid. The sid will always be NULL on unix, and 
the uid will always be -1 on Windows.

This is the full fix. If you want a short-term hack, then just disallow 
user=""/group="" on Windows by having the parse_unix_user always fail 
unless the value is "*", and don't have a parse_windows_user. Again only 
the system bus would ever use this feature anyway, and Windows has no 
system bus.

>> IIRC GetConnectionUnixUser is a function on the bus daemon that is
>> implemented by calling connection_get_unix_user(). You could add
>> GetConnectionWindowsUser implemented by calling
>> connection_get_windows_user(), or you could simply not have this
>> feature on Windows for now.
> Why is there such a different naming required ?  When I contact a dbus
> server and I like to know the user id of the server, why should I have
> to know if this is a windows or a unix dbus server ?  What I like to
> know is the id of the user under which the server is running to use this
> id in further calls to the server, isn't it ?

How is it useful for an application in one process to know a hash value 
used internally to libdbus in another process?

Havoc