removing dbus_getuid

Havoc Pennington hp at
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 
user="*" policies.

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, 
then have:
  dbus_credentials_match(DBusCredentials *credentials_from_socket,
                         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 
mechanism hook).

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 mailing list