Bug 146208
| Summary: | pg_dump is broken | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Chris Jones <rollercow> |
| Component: | selinux-policy-targeted | Assignee: | Daniel Walsh <dwalsh> |
| Status: | CLOSED ERRATA | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 3 | CC: | sitsofe, walters |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | RHBA-2005-251 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2005-01-31 14:22:36 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
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. 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. 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. Dan 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 :) 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. The updated selinux policy seems to fix things Thanks! 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 |
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: Always 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: