user auth patches

[Ralf Habacker]

Havoc Pennington schrieb:
> Hi,
>
> Ralf Habacker wrote:
>> Ralf Habacker schrieb:
>>> dbus-sysdeps-unix.h should not be included in windows, but it is 
>>> included in dbus-userdb.c and dbus-userdb-util.c. Should these files 
>>> are completly removed from the windows build ?
>>>
>
> Yes, they should not be required. I tried to remove all dbus-userdb.h 
> usage from cross-platform files, if I missed anything then let me know.
>
>> If I do so, I have to readd the following structs to dbus-sysdeps-win.h
>>
>
> Why? Trace the root causes and we'll get rid of them.
DBusUserInfo and DBUSGroupInfo are used in several functions in 
dbus-sysdeps-win.c and dbus-sysdeps-win-util.c. If i define this structs 
in that c files  I can compile libdbus.

but there are still many functions unresolved for example
    _DBUS_DEFINE_GLOBAL_LOCK(system_users)

 which is defined in dbus-userdb.c and dbus-userdb.c is not included on 
windows.

  
F:\daten\windbus\cvs-commit-3\dbus\dbus-internals.h(301):_DBUS_DECLARE_GLOBAL_LOCK 
(system_users);
  F:\daten\windbus\cvs-commit-3\dbus\dbus-threads.c(431):    LOCK_ADDR 
(system_users),
  
F:\daten\windbus\cvs-commit-3\dbus\dbus-userdb.c(221):_DBUS_DEFINE_GLOBAL_LOCK(system_users);
  F:\daten\windbus\cvs-commit-3\dbus\dbus-userdb.c(313):  _DBUS_LOCK 
(system_users);
  F:\daten\windbus\cvs-commit-3\dbus\dbus-userdb.c(324):  _DBUS_UNLOCK 
(system_users);

additional

 _dbus_homedir_from_username (username, &homedir) 

which are defined in dbus-userdb.c and referenced by dbus\dbus-keyring.c

and

_dbus_homedir_from_current_process()

referenced in
  
F:\daten\windbus\cvs-commit-3\dbus\dbus-auth-script.c(525):                
if (!_dbus_username_from_current_process (&u) ||
  F:\daten\windbus\cvs-commit-3\dbus\dbus-auth.c(788):  if 
(!_dbus_username_from_current_process (&username))
  F:\daten\windbus\cvs-commit-3\dbus\dbus-keyring.c(741):      if 
(!_dbus_username_from_current_process (&username) ||

addition

dbus-transport-socket.c _dbus_read_credentials_socket" in Funktion 
"_exchange_credentials".
dbus-transport-socket.c _dbus_send_credentials_socket" in Funktion 
"_exchange_credentials".

This was changed in version 1.5 -> I have updated the related functions 
in dbus-sysdeps-win.c

More will follow.

>
>> libdbus could the be build, bus dbus-daemon complains about many 
>> missing symbols (see below) Should they all have to be ported ? Why 
>> need I _unix functions on windows ?  Are there portable functions, 
>> which could be used by unix and windows to avoid duplicating code ?  
>> I thought that files like config-parser.c and dbus-transport.c  
>> should only use platform independent abstractions.
>
> The config file supports unix-only features. Most of these functions 
> are related to that. In the unix implementation of these functions I 
> tried to include in the docs what the windows implementation should do 
> (usually just fail immediately or set an error). So check the docs on 
> the unix version.
>
> If we had windows-only features in the config file, which we may 
> eventually, it would work similarly; on unix we would stub out the 
> functions related to those features.
>
> The basic meaning of _unix_ in the name of the function is that it is 
> only supposed to work on an _actual_ UNIX user or UNIX group. That is, 
> the function does not need to work on any kind of cross-platform idea 
> of a user or group. In other words, it can just fail always on Windows.
>
> Basically at this point there should be no abstraction of users or 
> groups. The public API has a string "sid" for Windows users, and a uid 
> for UNIX users, and the two are never treated interchangeably.
>
But if those function are limited to a specific platform, why should 
they defined on a platform on where they would never be used.

With your approach developers trying to understand the code see for 
example the function allow_unix_user_function() and they are thinking 
"Hmmh, I'm on windows. What does this unix function have to do with 
windows ? I have to dig more into ..... only to see after some time of 
investigation that this is only a dummy function." This makes the code 
harder to read and to understand.

Would it not be lesser work and more readable to simply comment out the 
related code on a not supported platform, which is done by many multiple 
platform projects like Qt and KDE  also in the core code ?

People reading the code say "hey this code is commented out on platform 
x so I don't need to dig more into to understand how the whole thing 
work." There are several places in the dbus code like this and for my 
opinion it makes it really hard to read.

I vote for making the internal api as simple as possible. If there are 
no problems with this point of view I would simply comment out the 
related parts.

> The one case where we pass around "windows user OR unix user" is the 
> DBusCredentials object, which explicitly can contain either.
Which still requires a dbus_uid_t on windows. I will take a deeper look 
into that stuff.

Ralf