This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux major release.  Product Management has requested further
review of this request by Red Hat Engineering, for potential inclusion in a Red
Hat Enterprise Linux Major release.  This request is not yet committed for
inclusion.

(In reply to comment #2)
> This request was evaluated by Red Hat Product Management for inclusion in a Red
> Hat Enterprise Linux major release.  Product Management has requested further
> ....

Can you please explain this statement?  All of the components listed in this ticket are supported in RHEL 6 - at this time, none of the components are a "technology preview" or otherwise marketed as not being supported.  This ticket references a possible problem with these supported components - it is not a request to add more components to RHEL6 or a future release.

That is a cookie cutter message that basically says, reporting a bug does not guarantee it will be fixed.  

Lets look at what is breaking in postgresql.

Collect the avc's after a restart in enforcing mode

ausearch -m avc -ts recent 

Then attach them here.

Also can you get the latest rhel6 setroubleshooter

latestrhel6 setroubleshoot
Build                                     Tag                   Built by
----------------------------------------  --------------------  ----------------
setroubleshoot-2.2.72-1.el6               RHEL-6-candidate      dwalsh

(In reply to comment #4)

> Collect the avc's after a restart in enforcing mode
> ausearch -m avc -ts recent 

The AVC's do not appear to be generated:

[root@RHEL6-64 ~]# /sbin/service postgresql start
Starting postgresql service:                               [FAILED]
[root@RHEL6-64 ~]# ausearch -m avc -ts recent
<no matches>
[root@RHEL6-64 ~]# 

> Also can you get the latest rhel6 setroubleshooter
> setroubleshoot-2.2.72-1.el6               RHEL-6-candidate      dwalsh    

Is there a publicly-accessible place from which I can get this version of the package?  The current FTP server has the old 2.2.52 versions under x86_64 and sources.

I believe this may be related to one of two things:

1. XFS, or
2. The fact that I am working with an alternate filesystem.

To test this theory, I created a new directory under / named /opt.pg; I then created a directory /opt.pg/pgdata and configured it exactly as noted above with regards to owner and chcon.  Finally, I modified /etc/init.d/postgresql script to point PG_HOME to /opt.pg/pgdata.  Postgres runs initdb and starts fine under this configuration.

I will make an ext4 filesystem, and mount it under /opt.ext4 and repeat the exercise to see if Postgres still runs under that condition.

Well xfs should work.  Since you are getting no AVC's on the xfs one, please try


# semodule -DB
# /sbin/service postgresql start
# ausearch -m avc -ts recent


And see if there is anything.

This is interesting.  I attempted this same exercise, except formatted the partition as ext4 and mounted it under /opt.ext4.  I then repeated the steps creating pgdata, chown and chcon, etc. under the new /opt.ext4/pgdata directory.  I get the same error with ext4 as I got with xfs.  I did finally get an AVC denial message:

time->Mon Apr 26 22:34:48 2010
type=SYSCALL msg=audit(1272335688.560:216): arch=c000003e syscall=4 success=yes exit=128 a0=1c07b30 a1=7fff50d92410 a2=7fff50d92410 a3=666e6f632e6c7173 items=0 ppid=1 pid=5251 auid=500 uid=26 gid=26 euid=26 suid=26 fsuid=26 egid=26 sgid=26 fsgid=26 tty=(none) ses=4 comm="postmaster" exe="/usr/bin/postgres" subj=unconfined_u:system_r:postgresql_t:s0 key=(null)
type=AVC msg=audit(1272335688.560:216): avc:  denied  { search } for  pid=5251 comm="postmaster" name="/" dev=sdc1 ino=2 scontext=unconfined_u:system_r:postgresql_t:s0 tcontext=system_u:object_r:file_t:s0 tclass=dir

This means there is no label on the directory.

Run restorecon on the directory.

restorecon -R -v /opt.ext4

After running restorecon, I was able to initdb and run postgres in both the XFS and ext4 mount points.

The question remains, however - why does selinuxtroubleshooter report some AVC denials and not others?

SELinux has the concept of dontaudit rules.  For many apps this is appropriate.  An app will try to access a file one way and then when it gets permission denied it will go another path.

For example login programs try to read /etc/shadow, when they get denied the execute unix_chkpwd which can read /etc/shadow.  If selinux reported everytime a login attempted to read /etc/shadow, it would flood the logs.

Not sure which dontaudit rule caused your checks to fail.  But I think if you try the next selinux-policy your problem might be fixed.

selinux-policy-3.7.19-30

Miroslav the fix to remove dontaudit rules on daemons search directories, should fix this.

Red Hat Enterprise Linux 6.0 is now available and should resolve
the problem described in this bug report. This report is therefore being closed
with a resolution of CURRENTRELEASE. You may reopen this bug report if the
solution does not work for you.