[Dovecot] root login is refused, but....

[Timo Sirainen]

On 30.6.2005, at 10:02, Andrew Hutchings wrote:

>> -ERR [IN-USE] Internal login failure. Refer to server log for more 
>> information.
>> Connection closed by foreign host.
>> robyt:~#
>> Why dovecot don't close the connection at user root?
>> With this system i may know the root password..
>
> Dovecot is hard coded to refuse the root use at the auth stage (when 
> passing the user/pass entered).
> You are right though, the root user should be rejected for the same 
> reason no matter what the password.  The current method could be used 
> to discover the root password.

The fix isn't simple though. Authentication works like:

1. login: send user/pass to auth
2. auth: validate the password against passdb and reply to login. if 
auth fails, delay the answer for ~2secs
3. login: send file descriptor to master and request a new imap/pop3 
process
4. master: request user information from auth
5. auth: check that master's request is valid and return user 
information if so
6. master: check that user info is valid (eg. UID isn't 0). if it's 
invalid or something failed, login is sent a failure reply and:
7. login: send "internal authentication error" to client and disconnect 
it

Probably the simplest fix would be to change step 7. to change the 
error message to same as it's normally and add a ~2second delay. But 
then the delay must be kept in sync between auth and login, and I don't 
really like that.

Second possibility would be to check userdb in step 2 already and save 
the information to the request so at step 5 there's no need to do 
second userdb lookup. If the UID is 0 (or not in valid range as 
specified in config file) treat the authentication as if it failed and 
do the ~2sec delay before replying. This could work I suppose, but it 
would use a bit more memory.

Third possibility would be to add the ~2sec delay in step 5 before 
replying to master. This has the downside that while master is waiting 
for the reply from auth, it's keeping the connection's file descriptor 
open in its process. Flooding Dovecot with valid passwords for invalid 
users could make master process run out of fds, which isn't good. But 
no-one should know the password for those users so maybe this isn't an 
issue.

I'm not really sure which one to implement. The second idea could have 
positive effect in general, making authentication somewhat faster when 
passdb and userdb lookups are done close to each others. It'd also make 
step 5 happen instantly because there's no need to do userdb lookup at 
that point anymore. But it'd take more memory and might have some other 
negative side effects that I can't think of now. Hmm..
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
URL: <http://dovecot.org/pipermail/dovecot/attachments/20050701/5f6c3c82/attachment-0001.bin>