Description of problem: postgresql-test regression tests fail when enforcement mode is on Version-Release number of selected component (if applicable): selinux-policy-targeted-1.17.30-2.66 How reproducible: 100% Steps to Reproduce: 1. Install postgresql (including postgresql-test), start server. 2. su postgres 3. cd /usr/lib/pgsql/test/regress 4. ./pg_regress.sh --schedule=parallel_schedule Actual results: Some tests fail. Expected results: No failure reported. Additional info: The problems come from ERROR: could not open file "/usr/lib/pgsql/test/regress/results/onek.data" for writing: Permission denied and ERROR: could not set permissions on directory "/usr/lib/pgsql/test/regress/testtablespace": Permission denied (the latter only if using Postgres 8.0) The /results and /testtablespace subdirectories are not normally present but are created as part of the test process. It's annoying that selinux will allow me to create a subdirectory and then not allow it to be written in :-(. Kernel log shows Jan 12 17:09:44 rh1 kernel: audit(1105567784.555:0): avc: denied { write } for pid=27450 exe=/usr/bin/postgres name=results dev=hda8 ino=2249520 scontext=roo t:system_r:postgresql_t tcontext=user_u:object_r:lib_t tclass=dir Jan 12 17:09:56 rh1 kernel: audit(1105567796.023:0): avc: denied { write } for pid=27761 exe=/usr/bin/postgres name=results dev=hda8 ino=2249520 scontext=roo t:system_r:postgresql_t tcontext=user_u:object_r:lib_t tclass=dir Jan 12 17:09:56 rh1 kernel: audit(1105567796.030:0): avc: denied { write } for pid=27761 exe=/usr/bin/postgres name=results dev=hda8 ino=2249520 scontext=roo t:system_r:postgresql_t tcontext=user_u:object_r:lib_t tclass=dir Jan 12 17:10:07 rh1 kernel: audit(1105567807.618:0): avc: denied { setattr } f or pid=27950 exe=/usr/bin/postgres name=testtablespace dev=hda8 ino=2249519 sco ntext=root:system_r:postgresql_t tcontext=user_u:object_r:lib_t tclass=dir
Oh, and another thing: while testing PG 8.0 I'm seeing Jan 12 17:26:35 rh1 kernel: audit(1105568795.575:0): avc: denied { getattr } for pid=282 11 exe=/usr/bin/postgres path=/usr/bin/postmaster dev=hda8 ino=1899828 scontext=root:system _r:postgresql_t tcontext=system_u:object_r:bin_t tclass=lnk_file The inode refers to the /usr/bin/postmaster symlink, and I think what is happening is that selinux is denying the right to read the symlink contents. Why is that?
chcon -R -t postgresql_db_t /usr/lib/pgsql/test/regress/testtablespace /usr/lib/pgsql/test/regress/results Does it work then? Adding the bin_t Dan
The chcon only works if the subdirectories already exist, which is a bit of a PITA because the test script deletes them and recreates them. Is there a way to associate the needed exception with the parent directory /usr/lib/pgsql/test/regress, instead?
The best idea would be to How about if we add the following to the end of /etc/selinux/targeted/src/context/files/file_context /usr/lib/pgsql/test/regres(/.*)? system_u:object_r:postgresql_db_t /usr/lib/pgsql/test/regress/.*\.so -- system_u:object_r:shlib_t /usr/lib/pgsql/test/regress/.*\.sh -- system_u:object_r:bin_t /usr/lib/pgsql/test/regress/pg_regress -- system_u:object_r:postgresql_exec_t Then do a restorecon -R -v /usr/lib/pgsql/test
Those files aren't really at issue. Most of the files in the regress directory are actually used by client-side programs which are not interfered with by SELinux (AFAIK anyway). The part that is tricky is that in some parts of the test, the postgresql daemon is told by the client-side script to write files under /usr/lib/pgsql/test/regress/ (specifically, under the results/ and testtablespace/ subdirectories). This is exactly the sort of thing that SELinux *should* complain about under normal circumstances. Probably I should just go ahead and put the chcon into the test sequence. So never mind about that. If you'll fix the /usr/bin/postmaster symlink issue for me, we can mark this bug closed.
Actually, I did just cause the build to include a "make check" ... but since that is running a non-installed postmaster, it won't trigger any SELinux violations. AFAICS the only way to discover this problem during build would be for the build to actually install Postgres, which hardly seems acceptable (even if it would work which I doubt ... we don't run builds as root).
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2005-251.html