Re: sepgsql seems rather thoroughly broken on Fedora 30 - Mailing list pgsql-hackers

From Mike Palmiotto
Subject Re: sepgsql seems rather thoroughly broken on Fedora 30
Date
Msg-id CAMN686F4MiHK9qn_CnNk4X1iDjFGDU8h6kb7iVCtbN4NEOVDwg@mail.gmail.com
Whole thread Raw
In response to Re: sepgsql seems rather thoroughly broken on Fedora 30  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: sepgsql seems rather thoroughly broken on Fedora 30  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Thu, Jul 18, 2019 at 11:06 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Mike Palmiotto <mike.palmiotto@crunchydata.com> writes:
> > On Wed, Jul 17, 2019 at 12:32 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> >> $ runcon -t sepgsql_regtest_user_t psql --help
> >> psql: fatal: could not look up effective user ID 1000: user does not exist

You can rule out SELinux for this piece by running `sudo setenforce
0`. If the `runcon ... psql` command works in Permissive we should
look at your audit log to determine what is being denied. audit2allow
will provide a summary of the SELinux denials and is generally a good
starting point:

# grep denied /var/log/audit/audit.log | audit2allow

If SELinux is indeed the issue here and you want to avoid doing all of
this detective work, it may be a good idea to just run a system-wide
restorecon (assuming you didn't already do that before) to make sure
your labels are in a decent state.

FWIW, this appears to be working on my recently-installed F30 VM:

% runcon -t sepgsql_regtest_user_t psql --help &> /dev/null
% echo $?
0

Hopefully a system-wide `restorecon` just magically fixes this for
you. Otherwise, we can start digging into denials.

-- 
Mike Palmiotto
Software Engineer
Crunchy Data Solutions
https://crunchydata.com



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: POC: Cleaning up orphaned files using undo logs
Next
From: Ian Barwick
Date:
Subject: Re: [PATCH] minor bugfix for pg_basebackup (9.6 ~ )