Bug 146208 - pg_dump is broken
Summary: pg_dump is broken
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy-targeted   
(Show other bugs)
Version: 3
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Daniel Walsh
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2005-01-25 23:33 UTC by Chris Jones
Modified: 2007-11-30 22:10 UTC (History)
2 users (show)

Fixed In Version: RHBA-2005-251
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-01-31 14:22:36 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2005:251 low SHIPPED_LIVE selinux-policy-targeted bug fix update 2005-06-09 04:00:00 UTC

Description Chris Jones 2005-01-25 23:33:12 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20050110 Firefox/1.0 (Debian package 1.0+dfsg.1-2)

Description of problem:
pg_dump doesnt work, looks selinux related

audit(1106618402.044:0): avc:  denied  { write } for  pid=12783 exe=/usr/bin/pg_dump path=/home/****/public_html/dbbackup dev=hdc2 ino=4735106 scontext=user_u:system_r:postgresql_t tcontext=system_u:object_r:user_home_t tclass=file
audit(1106625603.582:0): avc:  denied  { write } for  pid=19661 exe=/usr/bin/pg_dump path=/home/****/backup/dbbackup/nightlyvfv.pgdump dev=hdc2 ino=13189262 scontext=user_u:system_r:postgresql_t tcontext=system_u:object_r:user_home_t tclass=file
audit(1106625603.582:0): avc:  denied  { append } for  pid=19661 exe=/usr/bin/pg_dump path=/home/****/backup.txt dev=hdc2 ino=3113228 scontext=user_u:system_r:postgresql_t tcontext=system_u:object_r:user_home_t tclass=file
audit(1106695752.399:0): avc:  denied  { search } for  pid=14826 exe=/usr/bin/pg_dump name=rollercow dev=hdc2 ino=8224945 scontext=user_u:system_r:postgresql_t tcontext=system_u:object_r:user_home_t tclass=dir

Version-Release number of selected component (if applicable):
postgresql-7.4.6-1.FC3.2  selinux-policy-targeted-1.17.30-2.73

How reproducible:

Steps to Reproduce:
1. Have postgres installed and setup, with some databases
2. Attempt to dump a database useing pg_dump
3. Fail

Actual Results:  Not a lot, pg_dump doesnt return anything, 
useing -f it fails to create the file

Expected Results:  It should have either dumped the database to stdout, or the requested file

Additional info:

Comment 1 Tom Lane 2005-01-26 04:35:07 UTC
Reassigning to appropriate component ... Dan, pg_dump is not a daemon, and even if it were selinux 
has no damn business refusing writes to stdout.

Comment 2 Daniel Walsh 2005-01-26 20:57:57 UTC
If you change the context of pg_dump and pg_dumpall to bin_t

chcon -t bin_t /usr/bin/pg_dump /usr/bin/pg_dumpall

It should fix the problem.  I will update the policy.  It might need additional
fixes for strict policy though.

Comment 3 Daniel Walsh 2005-01-26 22:39:55 UTC
Fixed in selinux-policy-targeted-1.17.30-2.74  Should be available for testing.
 Please try it out.  You will need to do a restorecon -R -v /usr/bin  After you
install to remove the postgres_exec_t from the helper apps.


Comment 4 Colin Walters 2005-01-26 22:51:28 UTC
I think we really have to start working on automatic relabeling.  How are all
the FC3 postgres users going to know to run that command?  I doubt many are
going to look at this bug or even read the changelog.

For now perhaps we could just put a restorecon -v /usr/bin/pg_dump ... in the
%post section of selinux-policy-targeted?  At such point as we accumulate enough
of these fixes we could look at making it more efficient by only doing the
relabeling if we're upgrading from a version that required it, using the trigger
mechanism or something else.  If we've agreed though that we're going to try
hard to avoid changing file contexts, it could be quite a while before we
accumulate enough of the restorecon commands to worry about performance.  Even
if we do accumulate a lot, installing a new kernel will probably always
completely dominate policy postinst due to their O(N^3) or whatever hardlink
script :)

Comment 5 Daniel Walsh 2005-01-27 14:19:44 UTC
I agree, the problem is when do I clean the restorecon's out of the post scripts.
I think we ought to have this conversation on the SELinux or Fedora-SELinux list.

The problem here is that their is no easy way to judge what is installed and
what to cleanup.  Some cases you want to restore a single file, sometimes a
directory.  Ie what happens if we change an intermediate directory's context? 
Do we do 
restorecon -R on it?  I was thinking it would be kind of neat to do a diff
between the previously installed file context and the newly installed file
context, but file context, then restorecon on the differences.  Problem their is
figuring out which files are effected. 

Comment 6 Chris Jones 2005-01-28 21:15:52 UTC
The updated selinux policy seems to fix things

Comment 7 Tim Powers 2005-06-09 13:06:15 UTC
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.


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