Re: sepgsql seems rather thoroughly broken on Fedora 30
От | Mike Palmiotto |
---|---|
Тема | Re: sepgsql seems rather thoroughly broken on Fedora 30 |
Дата | |
Msg-id | CAMN686F4MiHK9qn_CnNk4X1iDjFGDU8h6kb7iVCtbN4NEOVDwg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: sepgsql seems rather thoroughly broken on Fedora 30 (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: sepgsql seems rather thoroughly broken on Fedora 30
|
Список | 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 по дате отправления: