Red Hat Bugzilla – Bug 585704
setroubleshoot does not report SELinux violations
Last modified: 2010-11-10 16:34:22 EST
Description of problem: While experimenting with an alternate configuration of Postgres, I cannot 'initdb' or 'start' the postgres service via /sbin/service. This is a SELinux error because when I set SELinux to 'Permissive' mode, I can initdb and start successfully. However, when it is set to 'Enforcing' and the postgres stat fails, I do not get any notification in the SELinux troubleshooter that there is a violation of policy. Version-Release number of selected component (if applicable): RHEL x86_64 running in Sun VirtualBox 3.1.6 r59338 setroubleshoot-plugins-2.1.36-1.el6.noarch setroubleshoot-2.2.52-1.el6.x86_64 setroubleshoot-server-2.2.52-1.el6.x86_64 selinux-policy-mls-3.7.17-5.el6.noarch selinux-policy-minimum-3.7.17-5.el6.noarch libselinux-utils-2.0.87-1.el6.x86_64 libselinux-2.0.87-1.el6.i686 libselinux-2.0.87-1.el6.x86_64 libselinux-devel-2.0.87-1.el6.x86_64 selinux-policy-3.7.17-5.el6.noarch selinux-policy-targeted-3.7.17-5.el6.noarch postgresql-devel-8.4.2-6.el6.x86_64 postgresql-libs-8.4.2-6.el6.x86_64 postgresql-server-8.4.2-6.el6.x86_64 postgresql-8.4.2-6.el6.x86_64 postgresql-libs-8.4.2-6.el6.i686 How reproducible: I was experimenting with hosting PostgreSQL databases on an XFS filesystem. Steps to Reproduce: 1. Under VirtualBox, create a 6.4 GB volume and attach it to the VM. Boot the VM. 2. Once booted, create a partition on this drive and make the filesystem like this: mkfs -t xfs -f /dev/sdb1 3. Mount this filesystem as /opt 4. Under /opt, create a directory, pgdata. Chown postgres:postgres pgdata. 5. chcon system_u:object_r:postgresql_db_t:s0 pgdata 6. Modify the file /etc/init.d/postgresql at approximately line 110 to change PGDATA to /opt/pgdata. 7. Modify the file /etc/init.d/postgresql at approximately line 250 to remove the call to 'restorecon' for $PGDATA. 8. Ensure that SELinux is in Enforcing mode via the GUI tool (System -> Administration -> SELinux Management). 9. Start the SETroubleshooter application via Applications -> System Tools -> SELinux Troubleshooter. 10. As root, run '/sbin/service postgresql initdb' 11. Note that it fails. 12. Put SELinux in Permissive mode using the GUI tool. 13. As root, run '/sbin/service postgresql initdb'. Note that it runs OK. 14. Put SELinux in Enforcing mode using the GUI tool. 15. As root, run '/sbin/service postgresql start'. Note that it fails. 16. Consult the file /var/lib/pgsql/pgstartup.log and see that there is a permission error reading /opt/pgdata/postgresql.conf. 17. Put SELinux in Permissive mode using the GUI tool. 18. As root, run '/sbin/service postgresql start'. Note that it runs. 19. As root, run '/sbin/service postgresql stop'. 20. Put SELinux in Enforcing mode using the GUI tool. 21. As root, run: su -l postgres -c "/usr/bin/postmaster -p '5432' -D '/opt/pgdata'" 22. Note that postmaster is running, and you can connect to it using the psql command line tool. 23. Note that during this exercise the SELinux troubleshooter did not display any errors. Actual results: Note that during this exercise the SELinux troubleshooter did not display any errors. Expected results: I would expect that SELinux troubleshooter would provide information on why SELinux is denying access to /opt/pgdata/postgresql.conf when I run postgres from the init script.
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.