[Dovecot] BUG: mishandling of username if it's a keyword?

[Timo Sirainen]

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