[Dovecot] New userdb backend for checkpassword like programs

[Sascha Wilde]

Sascha Wilde <wilde at intevation.de> writes:
> Timo Sirainen <tss at iki.fi> writes:
>> On Wed, 2008-10-22 at 16:15 +0200, Sascha Wilde wrote:
>>> There are more than 250LOC in deliver/auth-client.c and I wonder if
>>> there is already a higher level api for auth clients?  I would have
>>> expected something like this in lib-auth, but the stuff in there seems
>>> not to be what I'm looking for.  Any hints?
>>
>> plugins/expire-tool/auth-client.c has copy&pasted that code also.. So it
>> would be nice if it was put to lib-auth :)
>
> Ok, I'll consider doing so...  :)

Having a first look it turns out to be less straight forward then I
hoped it would be.  While there are significant amounts of code similar
in deliver/auth-client.c and expire/auth-client.c they differ in many
aspects:

1.) It seems that some code in deliver/auth-client.c has been revised
    after it was copied to expire/auth-client.c, this is a small problem
    as I would expect simply using the newer code to be the right
    thing[tm].

2.) The exported interface in the respective auth-client.h files is
    different.  The solution would be to figure out what the right
    interface would be and change the current code to use it.  My
    problem I'm not sure what the right interface would look like, for
    my use the one in expire/auth-client.h looks more compelling, what
    do you think?

3.) The deliver version does more than I need, and most certainly more
    than it should in the generic case: the most obvious example is that
    it sets up RESTRICT_* environment and calls
    restrict_access_by_env(TRUE); which surely is nothing I want to
    do in my code...

My current plan is to take only the code from deliver/auth-client and
check which parts I need, factor these out to new file in lib-auth
(unfortunately lib-auth/auth-client already exists) and finally ask the
author of the expire plugin to change his code so that it uses the new
stuff in lib-auth (I doubt that I will have the time to do this on my
own).

Obviously a god answer on 2. is badly needed...  ;-)

One final question:
All the code saves the gathered user data by setting the environment
accordingly (especially HOME, which is the one of interest for my
code) -- but in my case I'm requesting the data for foreign user so
setting HOME wouldn't be good idea.

I see two possible solutions:
- Simple and stupid: save HOME, call the client-auth code, read HOME and
  reset its value to the saved one.
- Clean but grows the API: export another function from auth-client,
  which does not set env-vars but returns the requested data in some
  struct.

Any thoughts on that?

cheers
sascha
-- 
Sascha Wilde                                          OpenPGP key: 4BB86568
http://www.intevation.de/~wilde/                  http://www.intevation.de/
Intevation GmbH, Neuer Graben 17, 49074 Osnabrück; AG Osnabrück, HR B 18998
Geschäftsführer:   Frank Koormann,  Bernhard Reiter,  Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 188 bytes
Desc: not available
Url : http://dovecot.org/pipermail/dovecot/attachments/20081023/60d22806/attachment.bin