user auth patches

[Havoc Pennington]

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.

> 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.

The one case where we pass around "windows user OR unix user" is the 
DBusCredentials object, which explicitly can contain either.

Havoc