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
