Hi,
I've just installed selinux on my FC3 server using the targeted policy, and everything went well except that I can no longer run /usr/bin/pg_dumpall as a root cron job for backing up postgresql databases. I get this sort of log message, even if I run pg_dump/pg_dumpall as the postgres user:
Dec 30 10:17:01 server2 kernel: audit(1104419821.285:0): avc: denied { execute_no_trans } for pid=24740 exe=/bin/bash path=/usr/bin/pg_dump dev=md0 ino=346137 scontext=user_u:system_r:postgresql_t tcontext=system_u:object_r:postgresql_exec_t tclass=file
For now, I've disabled the postgres protection using system-config-security-level, and it works fine - but postgresql is unprotected of course.
Is there a way of running pg_dump and pg_dumpall under selinux, without abandoning or rewriting the targeted policy?
- Mike
Dr. Michael J. Chudobiak wrote:
Hi,
I've just installed selinux on my FC3 server using the targeted policy, and everything went well except that I can no longer run /usr/bin/pg_dumpall as a root cron job for backing up postgresql databases. I get this sort of log message, even if I run pg_dump/pg_dumpall as the postgres user:
Dec 30 10:17:01 server2 kernel: audit(1104419821.285:0): avc: denied { execute_no_trans } for pid=24740 exe=/bin/bash path=/usr/bin/pg_dump dev=md0 ino=346137 scontext=user_u:system_r:postgresql_t tcontext=system_u:object_r:postgresql_exec_t tclass=file
For now, I've disabled the postgres protection using system-config-security-level, and it works fine - but postgresql is unprotected of course.
Is there a way of running pg_dump and pg_dumpall under selinux, without abandoning or rewriting the targeted policy?
- Mike
-- fedora-selinux-list mailing list fedora-selinux-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-selinux-list
Grab selinux-policy-targeted-1.17.30-2.62 off of ftp://people.redhat.com/dwalsh/SELinux/FC3
Daniel J Walsh wrote:
Is there a way of running pg_dump and pg_dumpall under selinux, without abandoning or rewriting the targeted policy?
Grab selinux-policy-targeted-1.17.30-2.62 off of
I still get errors. I can't run pg_dumpall as root or postgres:
[root@server2 log]# rpm -qa selinux-policy-targeted selinux-policy-targeted-1.17.30-2.62
[root@server2 log]# grep pg_dumpall messages Jan 4 09:50:13 server2 kernel: audit(1104850213.722:0): avc: denied { write } for pid=16053 exe=/usr/bin/pg_dumpall name=.s.PGSQL.5432 dev=md0 ino=213026 scontext=user_u:system_r:postgresql_t tcontext=root:object_r:tmp_t tclass=sock_file Jan 4 09:50:17 server2 kernel: audit(1104850217.630:0): avc: denied { write } for pid=16057 exe=/usr/bin/pg_dumpall name=.s.PGSQL.5432 dev=md0 ino=213026 scontext=user_u:system_r:postgresql_t tcontext=root:object_r:tmp_t tclass=sock_file Jan 4 09:50:29 server2 kernel: audit(1104850229.137:0): avc: denied { write } for pid=16133 exe=/usr/bin/pg_dumpall name=.s.PGSQL.5432 dev=md0 ino=213026 scontext=root:system_r:postgresql_t tcontext=root:object_r:tmp_t tclass=sock_file Jan 4 09:50:37 server2 kernel: audit(1104850237.546:0): avc: denied { write } for pid=16166 exe=/usr/bin/pg_dumpall name=.s.PGSQL.5432 dev=md0 ino=213026 scontext=user_u:system_r:postgresql_t tcontext=root:object_r:tmp_t tclass=sock_file
Any suggestions?
- Mike
Dr. Michael J. Chudobiak wrote:
Daniel J Walsh wrote:
Is there a way of running pg_dump and pg_dumpall under selinux, without abandoning or rewriting the targeted policy?
Grab selinux-policy-targeted-1.17.30-2.62 off of
I still get errors. I can't run pg_dumpall as root or postgres:
[root@server2 log]# rpm -qa selinux-policy-targeted selinux-policy-targeted-1.17.30-2.62
[root@server2 log]# grep pg_dumpall messages Jan 4 09:50:13 server2 kernel: audit(1104850213.722:0): avc: denied { write } for pid=16053 exe=/usr/bin/pg_dumpall name=.s.PGSQL.5432 dev=md0 ino=213026 scontext=user_u:system_r:postgresql_t tcontext=root:object_r:tmp_t tclass=sock_file Jan 4 09:50:17 server2 kernel: audit(1104850217.630:0): avc: denied { write } for pid=16057 exe=/usr/bin/pg_dumpall name=.s.PGSQL.5432 dev=md0 ino=213026 scontext=user_u:system_r:postgresql_t tcontext=root:object_r:tmp_t tclass=sock_file Jan 4 09:50:29 server2 kernel: audit(1104850229.137:0): avc: denied { write } for pid=16133 exe=/usr/bin/pg_dumpall name=.s.PGSQL.5432 dev=md0 ino=213026 scontext=root:system_r:postgresql_t tcontext=root:object_r:tmp_t tclass=sock_file Jan 4 09:50:37 server2 kernel: audit(1104850237.546:0): avc: denied { write } for pid=16166 exe=/usr/bin/pg_dumpall name=.s.PGSQL.5432 dev=md0 ino=213026 scontext=user_u:system_r:postgresql_t tcontext=root:object_r:tmp_t tclass=sock_file
Looks like postgresql is running under the wrong context.
Do a ps -eZ | grep postgres
It should not be running unconfined_t.
Any suggestions?
- Mike
On Tue, 2005-01-04 at 11:47 -0500, Daniel J Walsh wrote:
Dr. Michael J. Chudobiak wrote:
[root@server2 log]# grep pg_dumpall messages Jan 4 09:50:13 server2 kernel: audit(1104850213.722:0): avc: denied { write } for pid=16053 exe=/usr/bin/pg_dumpall name=.s.PGSQL.5432 dev=md0 ino=213026 scontext=user_u:system_r:postgresql_t tcontext=root:object_r:tmp_t tclass=sock_file Jan 4 09:50:17 server2 kernel: audit(1104850217.630:0): avc: denied { write } for pid=16057 exe=/usr/bin/pg_dumpall name=.s.PGSQL.5432 dev=md0 ino=213026 scontext=user_u:system_r:postgresql_t tcontext=root:object_r:tmp_t tclass=sock_file Jan 4 09:50:29 server2 kernel: audit(1104850229.137:0): avc: denied { write } for pid=16133 exe=/usr/bin/pg_dumpall name=.s.PGSQL.5432 dev=md0 ino=213026 scontext=root:system_r:postgresql_t tcontext=root:object_r:tmp_t tclass=sock_file Jan 4 09:50:37 server2 kernel: audit(1104850237.546:0): avc: denied { write } for pid=16166 exe=/usr/bin/pg_dumpall name=.s.PGSQL.5432 dev=md0 ino=213026 scontext=user_u:system_r:postgresql_t tcontext=root:object_r:tmp_t tclass=sock_file
Looks like postgresql is running under the wrong context.
Do a ps -eZ | grep postgres
It should not be running unconfined_t.
I don't see unconfine_t in those log messages, just lots of postgresql_t as the source context. Can you tell me what you are seeing?
thx - Karsten
Karsten Wade wrote:
On Tue, 2005-01-04 at 11:47 -0500, Daniel J Walsh wrote:
Dr. Michael J. Chudobiak wrote:
[root@server2 log]# grep pg_dumpall messages Jan 4 09:50:13 server2 kernel: audit(1104850213.722:0): avc: denied { write } for pid=16053 exe=/usr/bin/pg_dumpall name=.s.PGSQL.5432 dev=md0 ino=213026 scontext=user_u:system_r:postgresql_t tcontext=root:object_r:tmp_t tclass=sock_file Jan 4 09:50:17 server2 kernel: audit(1104850217.630:0): avc: denied { write } for pid=16057 exe=/usr/bin/pg_dumpall name=.s.PGSQL.5432 dev=md0 ino=213026 scontext=user_u:system_r:postgresql_t tcontext=root:object_r:tmp_t tclass=sock_file Jan 4 09:50:29 server2 kernel: audit(1104850229.137:0): avc: denied { write } for pid=16133 exe=/usr/bin/pg_dumpall name=.s.PGSQL.5432 dev=md0 ino=213026 scontext=root:system_r:postgresql_t tcontext=root:object_r:tmp_t tclass=sock_file Jan 4 09:50:37 server2 kernel: audit(1104850237.546:0): avc: denied { write } for pid=16166 exe=/usr/bin/pg_dumpall name=.s.PGSQL.5432 dev=md0 ino=213026 scontext=user_u:system_r:postgresql_t tcontext=root:object_r:tmp_t tclass=sock_file
Looks like postgresql is running under the wrong context.
Do a ps -eZ | grep postgres
It should not be running unconfined_t.
I don't see unconfine_t in those log messages, just lots of postgresql_t as the source context. Can you tell me what you are seeing?
thx - Karsten
I see that the sock_file was created under tmp_t which indicates a transition did not happen. Postgresql should have created the sock file under postgresql_tmp_t, so I surmized that the postgres daemon is running under unconfined_t.
Dan
selinux@lists.fedoraproject.org
-
Daniel J Walsh -
Dr. Michael J. Chudobiak -
Karsten Wade