Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 162543 - dovecot fails to authenticate IMAP user
Summary: dovecot fails to authenticate IMAP user
Alias: None
Product: Fedora
Classification: Fedora
Component: dovecot
Version: 4
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Daniel Walsh
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2005-07-05 23:32 UTC by Sergey V. Udaltsov
Modified: 2014-01-21 22:52 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2005-07-11 17:14:46 UTC

Attachments (Terms of Use)
dovecot.conf (deleted)
2005-07-06 23:34 UTC, Sergey V. Udaltsov
no flags Details
/etc/pam.d/dovecot (deleted)
2005-07-06 23:35 UTC, Sergey V. Udaltsov
no flags Details
/etc/pam.d/system-auth (deleted)
2005-07-06 23:36 UTC, Sergey V. Udaltsov
no flags Details

Description Sergey V. Udaltsov 2005-07-05 23:32:29 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050524 Fedora/1.0.4-4 Firefox/1.0.4

Description of problem:
dovecot fails to authentication client (Evolution) when run as service. If it is run just as /usr/sbin/dovecot - the authentication is ok. No selinux-related messages in /var/log/messages or dmesg. It seems this happened after last pam upgrade from FC4 updates - before it was ok 

Version-Release number of selected component (if applicable):
dovecot-0.99.14-4.fc4 pam-0.79-9.1 selinux-policy-targeted-1.23.18-17

How reproducible:

Steps to Reproduce:
1. Start dovecot as IMAP service
2. Launch Evolution and try to authenticate

Additional info:

Comment 1 John Dennis 2005-07-06 22:01:55 UTC
I cannot reproduce this using pam-0.79-9.1 and selinux-policy-targeted-1.23.18-17.

How are you authenticating your users? shadow? kerberos? ldap?

Please attach a copy of your /etc/dovecot.conf, /etc/pam.d/dovecot, and
/etc/pam.d/system-auth files.

Did you look in /var/log/audit/audit.log for errors?

Comment 2 John Dennis 2005-07-06 22:05:08 UTC
Out of curiosity how did you get pam-0.79-9.1? It's not a released rpm as far as
I can tell.

It does require audit-libs >= 0.9.7, what version of audit-libs is on your system?

Comment 3 John Dennis 2005-07-06 22:27:13 UTC
Is the audit daemon running? (/sbin/service auditd status)

Are you running targeted or strict policy? Strict has a known problem with the
latest auditing.

Do you build your own kernels? What kernel is on your system?

Comment 4 Sergey V. Udaltsov 2005-07-06 23:34:36 UTC
Created attachment 116445 [details]

Comment 5 Sergey V. Udaltsov 2005-07-06 23:35:45 UTC
Created attachment 116446 [details]

Comment 6 Sergey V. Udaltsov 2005-07-06 23:36:40 UTC
Created attachment 116447 [details]

Comment 7 Sergey V. Udaltsov 2005-07-06 23:43:57 UTC
I don't have /var/log/audit/audit.log. I don't have auditd service at all.
Should I install it? I upgraded FC3 to FC4 using standard upgrade procedure,
from CDs.

I am using targeted policy.

pam was taken from freshrpms, tupdates. 

My kernel is standard kernel-2.6.12-1.1387_FC4 - I just added a irrelevant
couple of external modules (ati - video, acerhk - keyboard, x10 - smart home

Actually, to be able to debug dovecot (store log to separate /var/log/dovecot),
I installed the policy sources and added domains/misc/local.te file:
allow dovecot_t var_log_t:dir { add_name search write };
allow dovecot_t var_log_t:file { append create getattr write };
allow dovecot_auth_t var_log_t:dir { add_name search write };
allow dovecot_auth_t var_log_t:file { append create getattr write };

Audit libs: audit-libs-0.9.15-1.FC4

Comment 8 John Dennis 2005-07-07 17:49:42 UTC
Thank you for attaching the files. Your config is very close to what I'm running
and I have the same versions of the software installed, but its working for me,
so I'm at a loss for what could be the problem. 

The audit daemon would be a great help. Since you did an FC3->FC4 upgrade you
would not have picked it up, its new in FC4. Please install the audit rpm and
start the auditd service (you may want to permantly turn on auditd with
chkconfig). You should then restart dovecot using the service command
(/sbin/service dovecot restart) and restart your evolution client (so it forces
a new imap login/authentication). This should force /var/log/audit/audit.log to
be written with useful information (you should see all dovecot authentication
actions, both sucessful and unsucessful as well as any SELinux avc messages
concerning policy violations). If its obvious from the audit log what's failing
let me know, if not attach the relevant part of the audit log.

A few more questions:

In Evolution what is the value of "Use Secure Connection" and the the value of
"Authentication Type"?

Also, in your initial report you said it failed when started as a service but
worked when started by hand, when you say started as a service do you mean after
reboot or do you mean anytime you issue "/sbin/service dovecot restart"? When it
works by hand, what user are you? are you starting it via sudo?

Comment 9 John Dennis 2005-07-07 18:32:38 UTC
Nevermind, I was just able to reproduce the failure finally. It does seem to be
a security policy issue. I'm investigating now ...

Comment 10 John Dennis 2005-07-07 18:48:25 UTC
Hmm... I spoke too soon in comment #9, I have not reproduced it :-(
Authentication seems to be working fine. I am getting some AVC messages for
dovecot, but authentication via pam is succeeding. I would suggest you disable
the auth_debug and auth_verbose in your dovecot.conf file, set SELinux to
relabel and reboot with the audit logger on. Are you then still having
authentication problems?

Comment 11 John Dennis 2005-07-07 19:33:37 UTC
Problem is found :-) The recent pam update added audit logging, all login
attempts are now audited. The problem showed up in process that was using pam to
authenticate that did not have permission to access the audit log. A new
selinux-policy-targeted rpm is being prepared as we speak, this problem has hit
a number of applications.

I am reassigning this to the owner of the security policy who will close this
bug out when then new policy is available (and hopefully will identify the rpm
version of the policy).

One note of caution, during testing we often observe the first login attempt
after upgrading fails for some unknown reason. If it does just try the login
again, it should work from that point forward.

Comment 12 Sergey V. Udaltsov 2005-07-07 22:17:33 UTC
Yes it is ok now. Thanks.

Note You need to log in before you can comment on or make changes to this bug.