BUG #1670: pg_dump fails on CentOS 4
The following bug has been logged online:
Bug reference: 1670
Logged by: Josh
Email address: josh@globalherald.net
PostgreSQL version: 8.0.2, 8.0.3
Operating system: CentOS 4
Description: pg_dump fails on CentOS 4
Details:
pg_dump, as packaged in postgresql-8.0.3-1PGDG.i686.rpm, fails with no
output whatsoever when run from a terminal window:
[josh@localhost ~]$ pg_dump -U username database > backup.sql
[josh@localhost ~]$
However, when run from within pgadmin3, it runs as it should.
When I download the source to 8.0.3 and compile it from scratch, the freshly
compiled pg_dump works as it should from any source (PGAdmin3, command line)
Tom,
Try turning off SELinux enforcement, or better update the selinux
policy package and do a restorecon on all of /usr/bin. The earlier
I'll definitely give this a try.
Does this policy also apply to binaries compiled on the local machine?
When I compiled PG803 from source, then copied pg_dump to /usr/bin as
root, pg_dump worked fine.
Thanks for the help!
--Josh
Import Notes
Reply to msg id not found: 18775.1116262344@sss.pgh.pa.us
"Josh" <josh@globalherald.net> writes:
The following bug has been logged online:
pg_dump, as packaged in postgresql-8.0.3-1PGDG.i686.rpm, fails with no
output whatsoever when run from a terminal window:
[josh@localhost ~]$ pg_dump -U username database > backup.sql
Try turning off SELinux enforcement, or better update the selinux
policy package and do a restorecon on all of /usr/bin. The earlier
releases of selinux-policy-targeted prevent pg_dump from writing on
/dev/tty :-( ... which makes it a bit hard to emit error messages...
regards, tom lane
josh@bitbuckets.com writes:
Does this policy also apply to binaries compiled on the local machine?
When I compiled PG803 from source, then copied pg_dump to /usr/bin as
root, pg_dump worked fine.
AFAIK the policy is driven off the pathname of the executable --- so it
doesn't matter who compiled pg_dump, only where it is installed.
Also, there is a notion of "labeling" which is basically an extension
of file access bits (see "ls -Z"). What restorecon basically does is
update the labeling to be what the current policy says it should be.
So I'd expect your homebuilt pg_dump to start failing also if you
restorecon it with the current policy.
On my FC3 machine, with a pretty up-to-date policy, I see
$ cd /usr/bin
$ ls -Z postgres postmaster pg_dump
-rwxr-xr-x root root system_u:object_r:bin_t pg_dump*
-rwxr-xr-x root root system_u:object_r:postgresql_exec_t postgres*
lrwxrwxrwx root root system_u:object_r:bin_t postmaster
The /dev/tty restriction is associated with the postgresql_exec_t
labeling. I believe that the policy bug was essentially due to someone
not understanding that pg_dump isn't used as a daemon ...
[ObDisclaimer: I'm not a SELinux guru and have probably missed lots of
fine points.]
regards, tom lane