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