Created attachment 141261 [details]
grep postfix /var/log/messages

Two things to add:

1. Something seems to be changing the context of /usr/libexec/postfix/lmtp - as
soon as I fix it, it's reverted back to the incorrect context. How would I go
about finding out what is doing this?

# date
Wed Jan 10 09:54:15 GMT 2007
# fixfiles -R postfix check
/sbin/restorecon reset /usr/libexec/postfix/lmtp context
system_u:object_r:postfix_smtp_exec_t:s0->system_u:object_r:postfix_exec_t:s0
# fixfiles -R postfix restore
# fixfiles -R postfix check
/sbin/restorecon reset /usr/libexec/postfix/lmtp context
system_u:object_r:postfix_smtp_exec_t:s0->system_u:object_r:postfix_exec_t:s0
# date
Wed Jan 10 09:54:26 GMT 2007

2. Bug 221347 seems to be a duplicate of this one.

The fixfiles weirdness in comment #2 is probably because lmtp is hardlinked to
smtp in /usr/libexec/postfix/. However
/etc/selinux/targeted/contexts/files/file_contexts defines different contexts
for them (lmtp is not explicitly defined).

/usr/libexec/postfix/.* --      system_u:object_r:postfix_exec_t:s0
/usr/libexec/postfix/smtp       --      system_u:object_r:postfix_smtp_exec_t:s0

This still doesn't explain why smtpd is trying to access /boot, /, and /home though.

I see that 221347 has been closed as the reporter was no longer experiencing the
bug. I am still seeing this with a regularly updated system.

Interestingly, this is not apparent when using evolution to send email, only
when using /bin/mail or sylpheed-claws (haven't tried other mailers).

*** Bug 221347 has been marked as a duplicate of this bug. ***

(In reply to comment #3)
> I see that 221347 has been closed as the reporter was no longer experiencing the
> bug. I am still seeing this with a regularly updated system.

my mistake -- it is still alive and kicking with FC6 (no problems with RHEL5b2
though); I just got confused by the bug not being reproducible 100% times.

> Interestingly, this is not apparent when using evolution to send email, only
> when using /bin/mail or sylpheed-claws (haven't tried other mailers).

For me Evolution (using /usr/sbin/sendmail) doesn't trigger this bug as well,
but Thunderbird (which cannot use sendmail directly) with SMTP to localhost does.

Created attachment 145732 [details]
grep postfix /var/log/audit/audit.log

This may be even more interesting than previous attachment (hopefully).

Ok we can dontaudit the getattr of /boot.
And I have fixed the file context of lmtp.

But what are the lnk_files tmp under the /var directory.  This seems to be a
local customization on your part and would require custom policy.  You can
generate custom policy to silance these, via
grep lnk_file /var/log/audit/audit.log | audit2allow -M mypostfix 

The other fixes will be in selinux-policy-2.4.6-28

(In reply to comment #7)
> Ok we can dontaudit the getattr of /boot.

Why does postfix need to look here at all, though?

I'm also seeing "getattr" to /home and "search" to / (see my attachment comment
#1). 

I'm no longer getting the "read"s to disk devices though.

I think it is listing the contents of /  And therefore triggering getattr access
checks.  Lots of apps do this, although I do not know why.  I do not work on
postfix code, but until SELinux things like this were always ignored.

Created attachment 154182 [details]
Record of IRC chat about this bug on #postfix

Just to try to put some life into this bug, here is the record of IRC chat I
had about this bug on #postifx @ freenode. The guy blames postfix checking for
free space on all partitions -- that could be the reason why it goes to /home,
/boot, /tmp (assuming they are all partitions).

Reporter, are they?

Created attachment 154317 [details]
output of zgrep postfix /var/log/audit/* | audit2allow -M mypostfix

Does this make any sense?

This looks like there is a lnk_file in /var somewhere that postfix is not
allowed to read.  Do you have a special way of setting up your /var partition? 
Could you attach the avc messages that are generating this te file.

Created attachment 155038 [details]
Part of the audit.log

Per the last comment.

Looks like you have /var/tmp as a symlink?

Other stangeness you your logs?

s2disk is trying to mounton /proc directory?

setroubleshoot is requesting execmem execstack?????

I have no idea about setroubleshoot (well, I guess you should know more about it
than I do ;-)). s2disk is screwed up -- don't bother, that was just my attempt
to make it work and I gave up in meantime and switched to suspend2.

I was chatting about this with jkubin and pointed him towards my audit log on
http://www.ceplovi.cz/matej/tmp/audit.log.bz2 Does it make any more sense to you?

When I will be back at home with my notebook, I will check out that /var/tmp
link -- why shouldn't it be a symlink to /tmp?

Created attachment 155267 [details]
/var/log/audit/audit.log

Created attachment 155268 [details]
even older audit logs from the same computer

Actually, it was even worse -- /var/tmp was a symlink to /usr/local/tmp ;-)
needless to say, that I have restored (and restoreconed) /var/tmp

Concerning setroubleshootd -- yes, it doesn't work for me. This is an example
from today's /var/log/messages

May 23 22:56:02 chelcicky setroubleshoot: 2007-05-23 22:56:02,586 [rpc.ERROR] at
tempt to open server connection failed: (111, 'Spojen\xc3\xad odm\xc3\xadtnuto')
(that's "Connection rejected" in English).

Just now working on finding the proper setroubleshoot bug in BZ.

re comment #19, is the setroubleshoot service running? First, check this:

% chkconfig --list setroubleshoot

Is it on? No?

then:

% chkconfig setroubleshoot on
% service setroubleshoot start

Created attachment 155647 [details]
current audit.log

Per request on fedora-selinux list

(In reply to comment #20)
> re comment #19, is the setroubleshoot service running? First, check this:

Of course, it is -- and after ten minutes of sealert trying to "Server Load" I
have killed it.

re comment #21 attachment, this appears to be a binary file with the wrong
content-type. I did look at the file via your URL in the email. These errors
look most unusual. Is this an FC6 release as the bugzilla states? Have you
loaded any package versions from rawhide? Have you relabeled your entire system?
What is the content of /var/log/setroubleshoot/setroubleshootd.log? This issue
should be split off from this bugzilla into it's own if you are still having
problems. 

Created attachment 158504 [details]
current audit.log

Just to update for Fedora 7. I have uninstalled postfix, because it seems to be
not that much maintained in Red Hat (e.g., it seems to me that maintainer of
postfix hasn't bothered to see this bug yet). Dan, if you think there is
something interesting for you in my logs, I can install it for you to do any
testing you want, but otherwise, I think you somebody can close this bug.

The only additional one that I see which is not in FC7 SELinux policy is 

allow postfix_master_t sendmail_t:process signal;

Which I am adding to selinux-policy-2.6.4-27.fc7.src.rpm

Do you still have the problems with postfix?

No, it's fine now (I think since selinux-policy-2.6.4-27.fc7).

O.k., I am closing this as "ERRATA", then.