Bug 144950 - Still need a couple selinux tweaks for PostgreSQL
Still need a couple selinux tweaks for PostgreSQL
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: selinux-policy-targeted (Show other bugs)
3
All Linux
medium Severity medium
: ---
: ---
Assigned To: Daniel Walsh
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-01-12 17:21 EST by Tom Lane
Modified: 2013-07-02 23:03 EDT (History)
1 user (show)

See Also:
Fixed In Version: RHBA-2005-251
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-06-09 09:06:08 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Tom Lane 2005-01-12 17:21:40 EST
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
Comment 1 Tom Lane 2005-01-12 17:30:47 EST
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?
Comment 2 Daniel Walsh 2005-01-13 07:53:43 EST
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
Comment 3 Tom Lane 2005-01-13 12:37:37 EST
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?
Comment 4 Daniel Walsh 2005-01-13 13:38:19 EST
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
Comment 5 Tom Lane 2005-01-13 14:22:07 EST
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.
Comment 7 Tom Lane 2005-01-13 16:16:21 EST
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).
Comment 9 Tim Powers 2005-06-09 09:06:08 EDT
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

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