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

Reply via email to