Re: sepgsql seems rather thoroughly broken on Fedora 30
Mike Palmiotto <mike.palmiotto@crunchydata.com>
From: Mike Palmiotto <mike.palmiotto@crunchydata.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers@lists.postgresql.org, Joe Conway <mail@joeconway.com>
Date: 2019-07-19T13:37:45Z
Lists: 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
Commits
-
Fix contrib/sepgsql test policy to work with latest SELinux releases.
- 0e259d4bc789 9.4.24 landed
- b22e249837ad 9.5.19 landed
- 0a9ba5baac7d 9.6.15 landed
- 5c3d47287fd7 10.10 landed
- 5a1c61bdf4c0 11.5 landed
- 665329abe7ef 12.0 landed
- f5a4ab23e42a 13.0 landed