If you just want to quickly work around it, I think you could give "userdb"
parameter to auth_stream_reply_init() which is TRUE for the userdb_reply and
FALSE the passdb reply. Then in auth_stream_reply_remove() and _find() and
_exists() skip the first parameter if userdb=TRUE. Hmm. That's probably what
I'll do for v2.1, and a bit larger cleanup for v2.2.
On 14.12.2012, at 20.37, Jack Bates wrote:
> It looks as if some things make extra passes. I'm still tracing it, but could
> we modify userdb_template_export to skip the user part?
>
> It's interesting as I noticed that user=%u in a static config still ends up
> having an issue, which implies it was processed twice (once to home, and
> again to mess up).
>
> My problem is that I am moving an existing userbase and my user "home" isn't
> going to be happy to change. lol
>
> I'll keep looking. I know it has to be treated carefully given that USER can
> be changed and it will effect all userdb types. Currently I'm testing with
> both ldap w/ prefetch and static userdb.
>
> Jack
>
> On 12/14/2012 12:29 PM, Timo Sirainen wrote:
>> Yes, it's a bug. Most importantly: I don't think this is a security hole,
>> except maybe in some very specific installations. It only affects usernames
>> that are the same as one of the "extra fields" in userdb. Such user needs to
>> log in with a valid username and password before this happens. What happens
>> is that when userdb sets the extra field, it thinks it's replacing an
>> existing field and removes the username. So the username gets replaced by
>> the next field. This often does mean that the user can log in using a wrong
>> username (e.g. user is "uid=1000"), but there's really no way to set that to
>> any specific username. So users can't read each others' mails. But because
>> the username is different from expected, it could cause some confusion.
>>
>> I was also a bit worried that it still could allow users to create such
>> accounts for some webmail providers, but pretty much all of them use
>> user@domain style account names, and those aren't affected. So practically
>> no possibility of this affecting anyone where admin doesn't explicitly
>> create such account.
>>
>> I'll get this fixed when I have a bit of time. The fix isn't as easy as I'd
>> like and it affects a large part of the authentication..
>>
>> On 14.12.2012, at 18.04, Jack Bates wrote:
>>
>>> Dec 14 14:33:14 test2 dovecot: auth: Debug: master userdb out:
>>> USER#0112033451009#011uid=503#011gid=503#011home=/nfs/maildir/vmail/home#011mail_location=maildir:~/Maildir
>>> Dec 14 14:37:25 test2 dovecot: auth: Debug: master userdb out:
>>> USER#011477757441#011home2#011uid=503#011gid=503#011home=/nfs/maildir/vmail/home2#011mail_location=maildir:~/Maildir
>>> Dec 14 15:44:23 test2 dovecot: auth: Debug: master userdb out:
>>> USER#0113466592257#011uid=503#011gid=503#011home=/nfs/maildir/vmail/home#011mail_location=maildir:~/Maildir
>>>
>>> Looking at the proper home2 account, it appears that the username "home" is
>>> being left out. This is definitely an issue with auth userdb.
>>>
>>> This was on 2.1.12. I upgraded.
>>>
>>> Jack
>>>
>>> On 12/14/2012 10:00 AM, Jack Bates wrote:
>>>> Additional info by switching the home= and uid= settings in the config.
>>>>
>>>> userdb {
>>>> args = home=/nfs/maildir/vmail/%u uid=vmail gid=vmail
>>>> mail_location=maildir:~/Maildir
>>>> driver = static
>>>> }
>>>>
>>>> We got the effective id, but then home was unset and the user became the
>>>> home setting. lol
>>>>
>>
>
