dovecot imap broken by apparmor policy

[Janne Snabb]

Syslog output:

Apr 29 10:59:06 host12 dovecot: imap(foobar): Error: fcntl(unlock) locking failed for file /home/foobar/Maildir/dovecot.index.log: No such file or directory
Apr 29 10:59:06 host12 dovecot: imap(foobar): Error: fstat() failed with file /home/foobar/Maildir/dovecot.index.log: No such file or directory
Apr 29 10:59:37 dovecot: last message repeated 122 times
Apr 29 11:00:38 dovecot: last message repeated 248 times
Apr 29 11:01:54 dovecot: last message repeated 203 times

audit.log, lots of entries similar to the following:

type=AVC msg=audit(1335712674.515:655016): apparmor="ALLOWED" operation="getattr" parent=10922 profile="/usr/sbin/dovecot//null-107//null-10b//null-118" name="/home/foobar/Maildir/.foobar/dovecot.index.log" pid=10937 comm="imap" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000

The apparmor policy is as shipped with 12.04. The strange thing here is that audit.log says that the access was allowed and the apparmor policy has "flags=(complain)", but the imap server still fails accessing some files in the Maildir folders.

Workaround:

# ln -s /etc/apparmor.d/usr.sbin.dovecot /etc/apparmor.d/disable/

After disabling the usr.sbin.dovecot apparmor policy everything works fine. There is no need to disable the "usr.lib.dovecot.imap" policy.

It looks like the imap process is incorrectly running under the dovecot main daemon's apparmor profile. And for some odd reason the profile is enforcing things even though it should be in "complain" mode. What are these "//null-NNN/" strings in the logged apparmor profile name? I do not know apparmor well enough to debug this further at this point.

Someone else has encountered this also, see thread at:

http://comments.gmane.org/gmane.mail.imap.dovecot/60533

ProblemType: Bug
DistroRelease: Ubuntu 12.04
Package: dovecot-imapd 1:2.0.19-0ubuntu1
ProcVersionSignature: User Name 3.2.0-24.37-virtual 3.2.14
Uname: Linux 3.2.0-24-virtual x86_64
ApportVersion: 2.0.1-0ubuntu7
Architecture: amd64
Date: Wed May 9 18:36:11 2012
ProcEnviron:
 SHELL=/bin/bash
 TERM=screen
 LANG=en_US.UTF-8
SourcePackage: dovecot
UpgradeStatus: Upgraded to precise on 2012-04-27 (12 days ago)
---
ApportVersion: 2.0.1-0ubuntu8
Architecture: amd64
DistroRelease: Ubuntu 12.04
InstallationMedia: Ubuntu-Server 12.04 LTS "Precise Pangolin" - Release amd64 (20120424.1)
Package: apparmor 2.7.102-0ubuntu3.1
PackageArchitecture: amd64
ProcEnviron:
 TERM=linux
 PATH=(custom, no user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcKernelCmdline: BOOT_IMAGE=/boot/vmlinuz-3.2.0-23-generic root=UUID=7e6df5b7-d31e-4757-a388-f4f477187a63 ro
ProcVersionSignature: Ubuntu 3.2.0-23.36-generic 3.2.14
Tags: precise
Uname: Linux 3.2.0-23-generic x86_64
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups:

[Janne Snabb (snabb)]

This looks like it could be an apparmor bug instead of dovecot bug, it just happens to manifest itself with dovecot. Adding "apparmor" in "affects".

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Jamie Strandboge (jdstrand)]

Thank you for using Ubuntu and reporting a bug. The 'null' lines are used when the profile is in complain mode. The apparmor log message states that the access was allowed, so I am not sure why it would be getting in the way.

Can you provide exact steps on how to reproduce this?

[Jamie Strandboge (jdstrand)]

Marking the dovecot task Invalid for now-- the apparmor profile is not shipped by default or enabled by dovecot and if there is a problem, it is with apparmor.

[Jamie Strandboge (jdstrand)]

Also, can you perform the following after seeing the error condition?
$ apport-collect 997269

This will provide logs and system information needed for diagnosing the problem.

[Janne Snabb (snabb)]

apport information

[Janne Snabb (snabb)]

apport information

[Janne Snabb (snabb)]

apport information

[Janne Snabb (snabb)]

apport information

[Janne Snabb (snabb)]

apport information

[Jamie Strandboge (jdstrand)]

Thanks for the extra information. Can you also attach the output of:
$ sudo aa-status

[Janne Snabb (snabb)]

I am able to reproduce this on a fresh install some times but not reliably. It would be great if someone who has some apparmor experience could have a look at this.

Steps to re-produce:

1. Install Ubuntu 12.04 Server from amd64 ISO in a virtual machine and make sure it is up to date:
# apt-get update && apt-get upgrade
# reboot

2. Install dovecot imapd and fetchmail for testing:
# apt-get install dovecot-imapd fetchmail
(I possibly needed to issue "service dovecot start" separately.)

3. Create user who receives mail:
# adduser foobar

4. Make mail directories for the user:
# mkdir -p /home/foobar/Maildir/{cur,new,tmp}

5. Send one e-mail to our user:
# (echo From: foo; echo; echo bar) > /home/foobar/Maildir/new/foo

6. Ensure correct ownership:
# chown -R foobar /home/foobar/Maildir

7. Try to retrieve the mail:
# fetchmail --user foobar --mda cat localhost
Observe success. Ignore warning about certificate. The mail should be output to stdout.

8. Install apparmor-profiles:
# apt-get install apparmor-profiles

9. Reboot to ensure fresh state:
# reboot

10. Send another e-mail:
# (echo From: foo; echo; echo bar) > /home/foobar/Maildir/new/foo2

11. Again, change ownership:
# chown foobar /home/foobar/Maildir/new/foo2

12. Try fetching mail again:
# fetchmail --user foobar --mda cat localhost
You may or may not see a failure here.

13. If there was no failure, open another terminal and log in as foobar, and create a pile of e-mails:
while true ; do ( echo From: foo; echo; echo bar ) > /home/foobar/Maildir/new/foo$SECONDS.$RANDOM ; done
Hit ctrl-C after some time.

14. Try fetching mail again:
# fetchmail --user foobar --mda cat localhost

15. If there was no failure, repeat steps 13 and 14 until the failure is observed. There will be error entries in /var/log/mail.err when the problem appears.

[Janne Snabb (snabb)]

On 07/08/2012 09:02 PM, Jamie Strandboge wrote:
> Thanks for the extra information. Can you also attach the output of:
> $ sudo aa-status

This is already there, in the attachment ApparmorStatusOutput.txt

[Launchpad Janitor (janitor)]

[Expired for apparmor (Ubuntu) because there has been no activity for 60 days.]

[martin suchanek (martin-suc)]

thanks for explanation and workaround. Helped me to solve it on 12.10

[Jamie Strandboge (jdstrand)]

Is this still a problem with Ubuntu 14.04? The dovecot profiles received a number of updates since this bug was reported.

[Ian Nicholson (imnichol)]

I am seeing this in 13.10 server.

[Launchpad Janitor (janitor)]

[Expired for apparmor (Ubuntu) because there has been no activity for 60 days.]

[Hasse Hagen Johansen (hasse-launchpad)]

For me it has been fixed by 14.04 and can now run with the different dovecot apparmor profiles swithed on

[Vin Shankar (v-shankar)]

In 14.04, the profile usr.lib.dovecot.imap-login does not allow the process to read from /var/run/dovecot/config, causing the client to see tls handshake timeouts if that profile is in enforce mode. Should I open a new bug?

[Christian Boltz (cboltz)]

Vin, this should be fixed since AppArmor bzr r2548 (but didn't make it into 14.04 yet).

You can get the latest profile from to http://bazaar.launchpad.net/~apparmor-dev/apparmor/master/files/head:/profiles/apparmor.d/ - download usr.lib.dovecot.imap-login and abstractions/dovecot-common (newly added and required by the updated imap-login profile).

If it works with the updated profile, please add a short success message here. Otherwise (or if you notice more/other issues), please open a new bugreport and add a pointer to the new report here.

[Valentin Lab (vaab)]

Hm, a fix was released... Can we have more info on what was fixed in apparmor itself ? (which commit, and which ubuntu/debian package/version) ?
My server is in 12.04.1 LTS and I don't want to upgrade the whole system it only for this, so I need more info.

I just upgraded my apparmor package from 2.7.102-0ubuntu3.7 to 2.7.102-0ubuntu3.10 ... But the changelog does not seem to list this bug as fixed::

  * 0022-aa-logprof-PUx_rewrite_fix-lp982619.patch: fix aa-logprof
    rewrite of PUx modes (LP: #982619)
  * 0023-lp1091642-parser-reset_matchflags.patch: prevent reuse of
    matchflags in parser dfa backend and add testcase demonstrating
    the problem (LP: #1091642)
  * 0024-profiles-allow_exo-open-lp987578.patch: allow exo-open to work
    within ubuntu-integration (LP: #987578)

Also, the current bug thread is not clear about if this is related to apparmor-profile or to an apparmor bug.

But, I don't have any apparmor-profile package installed and I am experiencing this issue randomly.

Namely:

Feb 26 10:45:36 mail dovecot: imap(foobar): Error: fcntl(unlock) locking failed for file /home/foobar/.mail/dovecot.index.log: No such file or directory
Feb 26 10:45:36 mail dovecot: imap(foobar): Error: fstat() failed with file /home/foobar/.mail/dovecot.index.log: No such file or directory
Feb 26 10:47:00 dovecot: last message repeated 15 times

Many thanks if anybody as any info on this topic.

[Seth Arnold (seth-arnold)]

Valentin, do you have any DENIED messages from AppArmor in your dmesg output, /var/log/syslog, or /var/log/audit/audit.log files?

Thanks