win32 dbus_connection_get_unix_user() problem
hp at redhat.com
Thu Mar 8 07:46:08 PST 2007
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():
> 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
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.)
> 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
>> 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?
More information about the dbus