Try the latest policy from updates-testing - it has a fix for this.

Does the selinux-policy update fix this? May I close the report?

well, I'm now running the following:
selinux-policy-2.6.4-13.fc7
selinux-policy-targeted-2.6.4-13.fc7

and although the dovecot-auth errors have disappeared, I still get a lot of
other errors. I'll attach these, but it looks like it may be due to upgrading
from FC6 to F7, with a migrated /home partition.

Created attachment 156760 [details]
Saved alerts

Note how most of these are related to files in /home/<username>/Mail (where
procmail puts these, having received them through fetchmail).

So, thinking about this more, this may not be due to an upgrade.

Do you have your home labelled properly?

Eh, define 'properly'. :-)

I didn't do any manual changes moving from FC6 to F7.  I did try a restorecon -R
/home/Mail just now, but that didn't fix the problem.

Well I don't understand selinux any more than you, but the text in your
attachment says something about labelling.

For example, my home is labelled this way:
/home/tjanouse - root:object_r:user_home_dir_t
/home/tjanouse/Mail - user_u:object_r:user_home_t
(I used ls -laZ to list it)

Bingo: somehow, my home (still?) had type default_t.  I did a chcon -R -t
user_home_t, and that got rid of almost all the errors.

Almost. I have one left:

avc: denied { search } for comm="dovecot" dev=dm-0 egid=500 euid=0
exe="/usr/sbin/dovecot" exit=0 fsgid=500 fsuid=0 gid=0 items=0 name="mnt"
pid=10417 scontext=user_u:system_r:dovecot_t:s0 sgid=0
subj=user_u:system_r:dovecot_t:s0 suid=0 tclass=dir
tcontext=system_u:object_r:mnt_t:s0 tty=(none) uid=0 

Any thoughts ?

Question is of course: why was my home still at default_t. What is supposed to
set my home to user_home_t ?

The only mentions of "mnt" in dovecot are
1) checking whether indexes are on NFS mounts
2) filesystem quota reporting plugin

Does it prevent dovecot from working or is it just a "warning"?

As to labelling of your home -- I don't know. I'd say the installer labels it
properly and I suppose there might be a way to force relabelling of the whole
filesystem hierarchy which should fix it as well.

Created attachment 156810 [details]
mnt alert

Here's the details on the mnt alert.  It says 'denied { search }', so I assume
this is an error, not a warning.

I tried disabling the quota plugin (by putting quota= in the plugin section of
dovecot.conf; I assume this is the way to do it), but I still get this error.

Strange. I can't make dovecot log that error. Could you strace -f it and attach
the relevant part, please? (something like "grep -C 100 mnt" may be enough)

Is /mnt mounted? Dovecot stat()s all mounted filesystems at startup to see if
NFS is used, and also when using filesystem quota. It just needs to find the
filesystem where mails are located.

Created attachment 156902 [details]
Requested strace

I think the selinux error messaging stating 'mnt' is slightly misleading.  The
only references to /mnt in the strace output are:

6579:[pid  9635] stat64("/mnt/pictures", {st_mode=S_IFDIR|S_ISVTX|0777,
st_size=4096, ...}) = 0
6580:[pid  9635] stat64("/mnt/audio", {st_mode=S_IFDIR|S_ISVTX|0777,
st_size=4096, ...}) = 0

(note: I have selinux in permissive mode)

Both /mnt/pictures and /mnt/audio are indeed mounted filesystems.

You can disable the check by putting nfs_check=no in the config file. I don't
think selinux should allow these accesses, so the warnings should be just ignored.

That seems to have fixed the problem. Thanks.

Perhaps, if selinux won't allow these accesses, the config file in the Fedora9
dovecot package should have nfs_check=no set.

It's not that selinux won't allow these accesses at all. It just doesn't allow
them in /mnt. It will allow dovecot to check whether, for example, /home or
/var/spool/mail is on a NFS-mounted volume.

Fair point.  Up to you to decide if/how to address this.

Selinux currently allows getattr all mountpoints.  Do you have avc messages from
when this happens?  Search /var/log/audit/audit.log

FIx for selinux in selinux-policy-2.6.4-38