Re: BUG #1670: pg_dump fails on CentOS 4

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: josh(at)bitbuckets(dot)com
Cc: Josh <josh(at)globalherald(dot)net>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #1670: pg_dump fails on CentOS 4
Date: 2005-05-16 17:46:11
Message-ID: 19573.1116265571@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

josh(at)bitbuckets(dot)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

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message David Walker 2005-05-17 00:48:39 Re: initdb fails on ultra2 sparc64, freebsd 5.4
Previous Message Tom Lane 2005-05-16 16:52:24 Re: BUG #1670: pg_dump fails on CentOS 4