win32 dbus_connection_get_unix_user() problem

[Havoc Pennington]

Hi,

Some of these places are unix-specific and just don't need a windows 
equivalent. Some of them you have already addressed by making dbus_uid_t 
a magic integer on windows, but that solution will not work when you 
cross the public API boundary into the bus daemon. However, as I've 
explained, the bus daemon does not even need to think about users on 
Windows, so in effect none of that code requires porting.

Ralf Habacker wrote:
> As far as I have learned you may answer, yes please add additional 
> windows specific user and gid types and rewrite the related parts for 
> windows.

Um, that would be "porting dbus to windows" which is something you are 
doing which I don't have time to do.

> Wouldn't here a platform independent *local* api be the better way to 
> avoid redundant logic and many duplicated stuff ?

I doubt it will help you that much overall, but yes a DBusUser opaque 
object (not typedef) instead of dbus_uid_t would probably make the code 
clearer. You effectively have an internal cross-platform object already 
due to the hash table approach that makes dbus_uid_t work on Windows 
internally, though; the only problem is when you're sending stuff over 
the wire or trying to use the public API, you can't use that. You won't 
be able to use an opaque DBusUser in those public contexts, either, though.

Look, the uid is essentially used for *TWO* purposes; for policies 
defined in the config file (does not apply to windows) and for 
authentication (does apply to windows). Most of the lines in your grep 
apply to the former.

There are a couple other small cases, like GetConnectionUnixUser and its 
convenience wrapper, and _dbus_change_identity(); both of these are 
unix-specific and don't make sense on Windows.

In fact since the only thing that makes sense on Windows is the 
authentication, an approach to consider is to make DBusCredentials 
opaque (with a unix-only "get uid" operation). Implement DBusCredentials 
for Windows, but many other uses of dbus_uid_t are unix specific so will 
be disabled rather than implemented on windows. For those you may as 
well keep dbus_uid_t.

When an operation *is not portable* then abstracting it isn't right; the 
abstraction needs to be at a higher or lower level. For example 
dbus_change_identity() is an inherently unix-only operation, so probably 
it should be a bug to call it on windows, and the windows config file 
should disallow specifying the user to run as.

Havoc