PostgreSQL Bugs - BUG #1670: pg_dump fails on CentOS 4

Author

BUG #1670: pg_dump fails on CentOS 4

Josh

2005-05-16, 11:23 am

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)

---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

Tom Lane

2005-05-16, 1:23 pm

"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

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

Tom Lane

2005-05-16, 1:23 pm

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:bi
n_t pg_dump*
-rwxr-xr-x root root system_u:object_r:po
stgresql_exec_t postgres*
lrwxrwxrwx root root system_u:object_r:bi
n_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

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql
.org

josh@bitbuckets.com

2005-05-17, 9:23 am

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

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql
.org so that your
message can get through to the mailing list cleanly

Sponsored Links