win32 dbus_connection_get_unix_user() problem

[Peter Kümmel]

Havoc Pennington wrote:
> Peter Kümmel wrote:
>> Isn't the code full of things like this?
>>
>> void
>> bus_connection_disconnected (DBusConnection *connection)
>> {
>> ....
>>   dbus_connection_set_unix_user_function (connection,
>>                                           NULL, NULL, NULL);
>>
>> ...
>>           if (dbus_connection_get_unix_user (connection, &uid))
>>
>>
>> Why is there no platform independent function call?
>> All is only
>> designed for unix (name of the function, type of uid), not in mind
>> that there could be other systems than unix.
> 
> The reason there's no platform-independent call is because it's doing
> something that only works on one platform.
> 
> "Cross-platform" does not mean there is no platform-specific code. It
> means as much code as can be cross-platform is, and then there is
> platform-specific code suitable for each platform.
> 
> As I explained in the other email I just sent, I do not want a
> "DBusUser" abstraction in the public API or config file, because dbus is
> not the right place for a whole bunch of cross-platform user and file
> APIs. So in the public API and config file there should be
> platform-specific concepts to a certain extent.
> 
> In a binding like QtDBus, you would then convert those platform-native
> concepts into the Qt abstractions for users and files and so forth.
> 
> However, QtDBus can't convert "DBusUser" to anything sensible, and no
> app programmer wants to write their app using "DBusUser" as the concept
> of a user. What people need is the unix user id and windows sid, and
> then the other APIs they are using, whether Qt or platform-specific,
> will have functions and objects that operate on the unix user id and
> windows sid. None of the other APIs they are using will support
> operations with a "DBusUser"
> 
> *Internally* to DBus we can have DBusUser. The problem you're running
> into is that dbus-daemon uses the *public* API, so you need to have some
> platform-specific code to deal with platform-specific aspects of the
> public API. However, we should be able to deal with this. It is not
> rocket science.
> 
>> The problem is, that we've implemented the unix interface
>> which is used all over the place, and now you are saying that you
>> don't wanna have used this interface on Windows.
> 
> It's not my random "don't wanna" - it doesn't make any sense on Windows,
> because *there aren't any unix user ids on windows*
> 
>> My idea is to replace all this unix function with platform
>> independent function calls.
> 
> You are welcome to do this as long as it does not introduce a DBusUser,
> DBusFile, etc. into the *public* API or config file, and as long as it
> *works*. Don't neglect the point that passing a process-specific made-up
> integer over the wire simply does not *work*.

I don't see a broblem to have DBusFile DBusUser in the API when there is a
'member function' to get the platform specific data type.
But I agree with you that our internal sid hashes are of no use for the
API clients.


> 
>> But your suggestion, when I understand it correctly,
>> is that we should just add the windows function,
>> e.g. dbus_connection_get_windows_user():
>>
> ...
>>           if (dbus_connection_get_windows_user(connection, &uid))
>>
> 
> Don't forget the other half of my suggestion, which is that Windows does
> not need this entire feature, because the system bus is bogus on
> Windows. So instead of doing this you can essentially just make the unix
> user stuff in bus/*.c get ignored when on Windows - reject any config
> file if the user attribute is anything other than user="*", and be sure
> user="*" works fine even if dbus_connection_get_unix_user returns false.
> 
> The places with unix in the public API are *intrinsically unix-specific*
> and simply don't make sense on Windows. My whole point is, don't port
> these; either make them no-ops if they make no sense on windows, or add
> windows-appropriate equivalent functionality.
> 
>> What happens when sometimes there is a new non-unix and non-windows
>> system?
> 
> Then we will have to port to that system.

Yes, this is the problem then we have to touch all the code again.

> 
>> Such a solution I would call a hack, the clean solution is
>> to have a interface.
> 
> You cannot implement an interface on Windows that looks like:
> 
>  interface Connection {
>    uid_t get_unix_user_id();
>  }

But:

#ifndef DBUS_WIN
typedef uid_t dbus_uid_t;
#else
typedef sid dbus_uid_t
#endif

interface Connection {
  dbus_uid_t get_id();
}

> 
> To implement this on Windows would require what I'm calling "unix
> emulation" and it's just not what anyone wants. If I'm writing a windows
> app, I don't want a uid_t that only libdbus understands when on Windows,
> but happens to be the same as uid_t on unix. That leads to apps that
> work fine on unix and don't work on Windows.
> 
> What you could implement on Windows is this:
> 
>   interface Connection {
>     DBusUserAbstractionObject get_user();
>   }
> 
Ah, ok...

> *However* to interoperate with any other APIs or in any way use
> DBusUserAbstractionObject, people would need:
> 
>   interface DBusUserAbstractionObject {
>     uid_t get_unix_user_id();
>     sid get_windows_sid();
>   }

My idea is more like this:

interface DBusUserAbstractionObject {
#ifndef DBUS_WIN
  uid_t get_native();
#else
  sid   get_native();
#endif
}


> 
> We could keep people from needing get_unix_user_id/get_windows_sid if we
> had a bunch of cross-platform operations on the
> DBusUserAbstractionObject: get_full_name(), get_groups(), etc.
> 
> However, *nobody* is going to write their whole app using
> DBusUserAbstractionObject, because this does not belong in dbus. What
> people will do instead is convert the DBus stuff into their own user
> abstraction, whether found in Qt or app-specific.

When DBusUserAbstractionObject is good it will be used ;)
But you are right it's not the main job of dbus.

> 
> Therefore, having a whole interface with get_full_name, get_groups, and
> so on in libdbus public API is just *broken*, nobody will use it except
> dbus itself. The right thing to have in libdbus public API is simply the
> unix user id and windows sid, and then people can *convert* those into
> whatever abstraction they are using.
> 
> We might have DBusUserAbstractionObject *inside* dbus, but it can't
> *leak out* or it's just bloat and confusing.
> 
> Since we use the user id in only one or two functions, simply offering
> windows and unix flavors that take either uid_t or an sid is by far the
> cleanest and simplest approach, compared to having a
> DBusUserAbstractionObject with only two methods
> (get_unix_id/get_windows_sid).
> 
> Havoc
> 


-- 
Peter Kümmel