Bug 470665 - Numerous AVC's from postfix
Numerous AVC's from postfix
Product: Fedora
Classification: Fedora
Component: selinux-policy (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Daniel Walsh
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2008-11-08 11:45 EST by Tom Diehl
Modified: 2008-11-11 08:39 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-11-11 08:39:42 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Copy of AVC's from the audit log. (6.61 KB, text/plain)
2008-11-08 11:45 EST, Tom Diehl
no flags Details
Output of "grep named_conf_t /etc/selinux/targeted/contexts/files/*" (1013 bytes, text/plain)
2008-11-10 20:40 EST, Tom Diehl
no flags Details

  None (edit)
Description Tom Diehl 2008-11-08 11:45:07 EST
Created attachment 322954 [details]
Copy of AVC's from the audit log.

Description of problem:

I am getting AVC's when I reload the postfix config or run mailq.

Version-Release number of selected component (if applicable):
(tigger pts3) $ rpm -qa | grep -i selinux
(tigger pts3) $ rpm -q postfix
(tigger pts3) $

How reproducible:

Every time
Steps to Reproduce:
1. run postfix reload or mailq
Actual results:
AVC's in log

Expected results:
No AVC's

Additional info:
I ran setenforce 0 ; restorecon -v -R / ; setenforce 1 before I sent this bug to be sure it was not a labeling problem.
Comment 1 Daniel Walsh 2008-11-10 10:45:17 EST
You or some program have labeled a file/direcory named_conf_t, that should not be labeled this.

# grep named_conf_t /etc/selinux/targeted/contexts/files/*

# ls -lZd /
Comment 2 Tom Diehl 2008-11-10 20:40:38 EST
Created attachment 323140 [details]
Output of "grep named_conf_t /etc/selinux/targeted/contexts/files/*"
Comment 3 Tom Diehl 2008-11-10 22:11:31 EST
I relabeled the machine again during a reboot and the problem seems to have gone away. I do not understand this since I ran restorecon -vR / before the last policy update. After the reboot ls -lZR only shows 3 files on the system with a named_conf_t context.

Is there a difference between doing a restorecon -vR / and doing touch /.autorelabel and rebooting? Maybe that is what I do not understand.

Sorry for the noise and Thanks for the help.
Comment 4 Daniel Walsh 2008-11-11 08:39:42 EST
No they should be equivalent.  The only real difference is /.autorelabel happens before most processes are started so there is less chance of a process running with the wrong context and creating files with the wrong context after relabeling.

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