user auth patches
ralf.habacker at freenet.de
Thu Jun 14 10:01:36 PDT 2007
Havoc Pennington schrieb:
> 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
which is defined in dbus-userdb.c and dbus-userdb.c is not included on
_dbus_homedir_from_username (username, &homedir)
which are defined in dbus-userdb.c and referenced by dbus\dbus-keyring.c
if (!_dbus_username_from_current_process (&u) ||
(!_dbus_username_from_current_process (&username) ||
dbus-transport-socket.c _dbus_read_credentials_socket" in Funktion
dbus-transport-socket.c _dbus_send_credentials_socket" in Funktion
This was changed in version 1.5 -> I have updated the related functions
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
> 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.
More information about the dbus