dovecot - Dec 2012 - passdb to add extra fields?

Some passdbs like PAM can't really return any extra fields. Also some
people have wanted to combine users' data from different passdb/userdbs
so that for example you'd have userdb passwd give the uid/gid/home, but
then you'd also have some other userdb give quota limits.

So I was thinking something like this:

passdb {
  driver = pam
}
passdb {
  driver = sql
  include = yes
}

or:

userdb {
  driver = passwd
}
userdb {
  driver = passwd-file
  include = yes
}

I'm not sure about two things:

1) Should there be a way to replace all of the existing fields instead
of just adding new ones?

2) Any thoughts of a better name than "include"? With passdb it would
mean that it's included only when the authentication failed for some
other passdb. With userdb it means it's included only if a previous
userdb lookup succeeded.

Also there are already "deny" and "pass" settings.
Interaction with them
can be somewhat confusing.. Maybe all of these should be replaced with:

type=deny: Same as old deny=yes (deny auth if user is in list)
type=precondition(?): Same as pass=yes (require another passdb to match)
type=postcondition(?): Require user to exist in this passdb/userdb as
well, adding any extra fields in it.
type=add: Add any extra fields, if the user exists at all.

(Better ideas for the names here? Is even "type" a good name?)

Then maybe a new setting to delete existing extra fields .. or perhaps
just extend passdb { override_fields } so that having "-field" would
delete the field if it already existed..

On Tue, Dec 18, 2012 at 4:12 PM, Timo Sirainen <tss at iki.fi> wrote:
> [[...]]]
> 2) Any thoughts of a better name than "include"? With passdb it
would
> mean that it's included only when the authentication failed for some
> other passdb. With userdb it means it's included only if a previous
> userdb lookup succeeded.
>
Amend  ??

At 11PM +0200 on 18/12/12 you (Timo Sirainen) wrote:
> Some passdbs like PAM can't really return any extra fields. Also some
> people have wanted to combine users' data from different passdb/userdbs
> so that for example you'd have userdb passwd give the uid/gid/home, but
> then you'd also have some other userdb give quota limits.
> 
> So I was thinking something like this:
> 
> passdb {
>   driver = pam
> }
> passdb {
>   driver = sql
>   include = yes
> }
> 
> or:
> 
> userdb {
>   driver = passwd
> }
> userdb {
>   driver = passwd-file
>   include = yes
> }
> 
> I'm not sure about two things:
> 
> 1) Should there be a way to replace all of the existing fields instead
> of just adding new ones?
> 
> 2) Any thoughts of a better name than "include"? With passdb it
would
> mean that it's included only when the authentication failed for some
> other passdb. With userdb it means it's included only if a previous
> userdb lookup succeeded.
> 
> Also there are already "deny" and "pass" settings.
Interaction with them
> can be somewhat confusing.. Maybe all of these should be replaced with:
> 
> type=deny: Same as old deny=yes (deny auth if user is in list)
> type=precondition(?): Same as pass=yes (require another passdb to match)
> type=postcondition(?): Require user to exist in this passdb/userdb as
> well, adding any extra fields in it.
> type=add: Add any extra fields, if the user exists at all.
> 
> (Better ideas for the names here? Is even "type" a good name?)
This sounds like the nsswitch.conf [notfound=continue] stuff, perhaps
you could use those names? 

    Status
    success     entry found
    notfound    entry definitely not found
    tryagain    database temporarily unavailable
    unavail     database not responding (an error of some kind)

    Action
    return      return the current result
    continue    try the next db and accumulate fields

with defaults of

    success = return
    notfound = continue
    tryagain = continue
    unavail = continue

You could potentially add other actions, like 'retry' which waits a bit
and retries. Some sort of 'tempfail' action, which returns temporary
failure to the client, would be good, but I don't think IMAP supports
that, unless you just drop the connection and assume the client will
reconnect and retry.

That would mean your first example would need to be

    passdb {
      driver = pam
      success = continue
    }
    passdb {
      driver = sql
    }

You could also add an 'override' key so that with this

    userdb {
        driver = passwd
        success = continue
    }
    userdb {
        driver = sql
    }

the SQL can't set 'home' (because passwd has already set it) but
with
this

    userdb {
        driver = passwd
        success = continue
    }
    userdb {
        driver = sql
        override = home
    }

it can.

Ben