Re: [Dovecot] passdb to add extra fields?
Added basically this: http://hg.dovecot.org/dovecot-2.2/rev/d60aa734c72d
Hopefully I didn't break peoples' authentications too much. :)
On 30.1.2013, at 15.49, Timo Sirainen wrote:
> On 19.12.2012, at 0.24, Ben Morrow wrote:
>
>>> 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.
>>
>> This sounds like the nsswitch.conf [notfound=continue] stuff, perhaps
>> you could use those names?
>>
>> Status
>> success entry found
>> notfoundentry definitely not found
>> tryagaindatabase temporarily unavailable
>> unavail database not responding (an error of some kind)
>
> I wonder what's the difference between tryagain and unavail. Sounds like the
> same thing to me.
>
>> Action
>> return return the current result
>> continuetry 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.
>
> Hmm. I guess this would work, with defaults:
>
> passdb {
> skip = never
> success = return-ok
> notfound = continue
> unavail = continue
> }
>
> The possible values for skip:
> - never: always do this passdb lookup
> - authenticated: skip if user is already authenticated by a previous passdb
> - unauthenticated: skip if user isn't authenticated
>
> The possible values for success/notfound/unavail:
> - return, return-ok, return-fail
> - continue, continue-ok, continue-fail
>
> where return/continue preserves the success-status without changing it, while
> the -ok and -fail variants change the success-status. The default status is
> fail, only return-ok / continue-ok changes that.
>
> So:
>
> - deny=yes would be success=return-fail.
>
> - pass=yes would be success=continue (or continue-fail, but usually that
> would be the same)
>
> - Two passdbs, second one adding extra fields:
>
> a) require user to be in both: passdb { success = continue }, passdb { skip =
> unauthenticated }
> b) don't require user in the second: passdb { success = continue-ok }, passdb
> { skip = unauthenticated }
>
> - 3 passdbs, with first two authenticating and last one adding extra fields:
>
> passdb { success = continue }, passdb { success = continue skip =
> authenticated }, passdb { skip = unauthenticated }
>
> I think you can do pretty much any wanted combination with these. Also. I
> think result_ prefix would be good, too lazy to update the rest of the mail
> now. So result_success, result_notfound and result_unavail.
>
Re: [Dovecot] passdb to add extra fields?
At 3PM +0200 on 30/01/13 you (Timo Sirainen) wrote:
> On 19.12.2012, at 0.24, Ben Morrow wrote:
>
> > This sounds like the nsswitch.conf [notfound=continue] stuff, perhaps
> > you could use those names?
> >
> >Status
> >success entry found
> >notfoundentry definitely not found
> >tryagaindatabase temporarily unavailable
> >unavail database not responding (an error of some kind)
>
> I wonder what's the difference between tryagain and unavail. Sounds
> like the same thing to me.
I think it's intended to distinguish between temporary and permanent
failures (like 400 and 500 SMTP errors), so for instance 'LDAP server
not responding' would be tryagain, and 'LDAP server returned permission
denied' would be unavail. The difference would only be useful if Dovecot
was going to retry in some cases, or could return a 'temporary failure'
indication to the client.
> Hmm. I guess this would work, with defaults:
>
> passdb {
> skip = never
> success = return-ok
> notfound = continue
> unavail = continue
> }
>
> The possible values for skip:
> - never: always do this passdb lookup
> - authenticated: skip if user is already authenticated by a previous passdb
> - unauthenticated: skip if user isn't authenticated
>
> The possible values for success/notfound/unavail:
> - return, return-ok, return-fail
> - continue, continue-ok, continue-fail
>
> where return/continue preserves the success-status without changing
> it, while the -ok and -fail variants change the success-status. The
> default status is fail, only return-ok / continue-ok changes that.
>
> So:
>
> - deny=yes would be success=return-fail.
>
> - pass=yes would be success=continue (or continue-fail, but usually
> that would be the same)
>
> - Two passdbs, second one adding extra fields:
>
> a) require user to be in both: passdb { success = continue }, passdb {
> skip = unauthenticated }
> b) don't require user in the second: passdb { success = continue-ok },
> passdb { skip = unauthenticated }
>
> - 3 passdbs, with first two authenticating and last one adding extra fields:
>
> passdb { success = continue }, passdb { success = continue skip =
> authenticated }, passdb { skip = unauthenticated }
>
> I think you can do pretty much any wanted combination with these.
> Also. I think result_ prefix would be good, too lazy to update the
> rest of the mail now. So result_success, result_notfound and
> result_unavail.
Looks good to me.
Ben
Re: [Dovecot] passdb to add extra fields?
On 30.1.2013, at 15.49, Timo Sirainen wrote:
> Hmm. I guess this would work, with defaults:
>
> passdb {
> skip = never
> success = return-ok
> notfound = continue
> unavail = continue
> }
Oh, except instead of "notfound" it has to be "failure". Failures could be
divided into "password mismatch" and "user doesn't exist", but some passdbs
can't tell the difference (e.g. PAM).
Re: [Dovecot] passdb to add extra fields?
On 19.12.2012, at 0.24, Ben Morrow wrote:
>> 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.
>
> This sounds like the nsswitch.conf [notfound=continue] stuff, perhaps
> you could use those names?
>
>Status
>success entry found
>notfoundentry definitely not found
>tryagaindatabase temporarily unavailable
>unavail database not responding (an error of some kind)
I wonder what's the difference between tryagain and unavail. Sounds like the
same thing to me.
>Action
>return return the current result
>continuetry 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.
Hmm. I guess this would work, with defaults:
passdb {
skip = never
success = return-ok
notfound = continue
unavail = continue
}
The possible values for skip:
- never: always do this passdb lookup
- authenticated: skip if user is already authenticated by a previous passdb
- unauthenticated: skip if user isn't authenticated
The possible values for success/notfound/unavail:
- return, return-ok, return-fail
- continue, continue-ok, continue-fail
where return/continue preserves the success-status without changing it, while
the -ok and -fail variants change the success-status. The default status is
fail, only return-ok / continue-ok changes that.
So:
- deny=yes would be success=return-fail.
- pass=yes would be success=continue (or continue-fail, but usually that would
be the same)
- Two passdbs, second one adding extra fields:
a) require user to be in both: passdb { success = continue }, passdb { skip =
unauthenticated }
b) don't require user in the second: passdb { success = continue-ok }, passdb {
skip = unauthenticated }
- 3 passdbs, with first two authenticating and last one adding extra fields:
passdb { success = continue }, passdb { success = continue skip = authenticated
}, passdb { skip = unauthenticated }
I think you can do pretty much any wanted combination with these. Also. I think
result_ prefix would be good, too lazy to update the rest of the mail now. So
result_success, result_notfound and result_unavail.
Re: [Dovecot] passdb to add extra fields?
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
notfoundentry definitely not found
tryagaindatabase temporarily unavailable
unavail database not responding (an error of some kind)
Action
return return the current result
continuetry 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
Re: [Dovecot] passdb to add extra fields?
On Tue, Dec 18, 2012 at 4:12 PM, Timo Sirainen 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 ??
[Dovecot] 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..
