hp at redhat.com
Tue May 29 13:24:31 PDT 2007
I would start at a high level.
The bus policy stuff IMO is just unix-specific. For this, the answer on
Windows could be that the user="" stuff can't be in the config file, or
that only user="*" is allowed.
This could very simply be implemented by having the user-related methods
act like there's nobody in the user database, perhaps. Or just if
dbus_connection_get_unix_user() fails then handle it by only matching
So for BusPolicy, perhaps leave it as uid.
If that makes sense, the question is what are the other uses of the user
The other one I can think of is authentication. This one probably makes
sense on Windows, and could be handled by doing all the auth stuff with
usernames as strings, potentially, make DBusCredentials more opaque,
const char *username_from_auth_protocol);
or something along those lines.
where on Linux the DBusCredentials would contain a uid and on Windows it
would contain a string or whatever is available (maybe nothing - maybe
on Windows there is no credentials method and so dbus_credentials_match
just always returns false - in this case, you could move the EXTERNAL
auth mechanism to a unix-only file - add a "platform_specific" auth
Anyway, I'm not sure of the details. The point is, consider addressing
it in each specific place (policies, auth, ... ?) by adding an
appropriate abstraction that makes good sense and can do the "native"
thing on each platform.
More information about the dbus