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

I tried to run the contrib/sepgsql tests, following the instructions,
on a recently-set-up Fedora 30 machine.  I've done that successfully
on previous Fedora releases, but it's no go with F30.

First off, building the sepgsql-regtest.pp policy file spews
a bunch of complaints that I don't recall having seen before:

$ make -f /usr/share/selinux/devel/Makefile
/usr/share/selinux/devel/include/services/container.if:14: Error: duplicate definition of container_runtime_domtrans().
Originaldefinition on 14. 
/usr/share/selinux/devel/include/services/container.if:41: Error: duplicate definition of container_runtime_run().
Originaldefinition on 41. 
/usr/share/selinux/devel/include/services/container.if:61: Error: duplicate definition of container_runtime_exec().
Originaldefinition on 61. 
/usr/share/selinux/devel/include/services/container.if:80: Error: duplicate definition of container_read_state().
Originaldefinition on 80. 
... more of the same ...
/usr/share/selinux/devel/include/services/container.if:726: Error: duplicate definition of docker_stream_connect().
Originaldefinition on 726. 
/usr/share/selinux/devel/include/services/container.if:730: Error: duplicate definition of docker_spc_stream_connect().
Originaldefinition on 730. 
/usr/share/selinux/devel/include/services/container.if:744: Error: duplicate definition of container_spc_read_state().
Originaldefinition on 744. 
/usr/share/selinux/devel/include/services/container.if:763: Error: duplicate definition of container_domain_template().
Originaldefinition on 763. 
/usr/share/selinux/devel/include/services/container.if:791: Error: duplicate definition of container_spc_rw_pipes().
Originaldefinition on 791. 
Compiling targeted sepgsql-regtest module
Creating targeted sepgsql-regtest.pp policy package
rm tmp/sepgsql-regtest.mod tmp/sepgsql-regtest.mod.fc
$

The sepgsql-regtest.pp file is created anyway, and it seems to
load into the kernel OK, so maybe these are harmless?  Or not.

I got through the remaining steps OK, until getting to actually
running the test script:

$ ./test_sepgsql

============== checking selinux environment           ==============
checking for matchpathcon           ... ok
checking for runcon                 ... ok
checking for sestatus               ... ok
checking current user domain        ... unconfined_t
checking selinux operating mode     ... enforcing
checking for sepgsql-regtest policy ... ok
checking whether policy is enabled  ... on
on
checking whether we can run psql    ... failed

/home/tgl/testversion/bin/psql must be executable from the
sepgsql_regtest_user_t domain. That domain has restricted privileges
compared to unconfined_t, so the problem may be the psql file's
SELinux label. Try

  $ sudo restorecon -R /home/tgl/testversion/bin

Or, using chcon

  $ sudo chcon -t user_home_t /home/tgl/testversion/bin/psql


(BTW, what's that extra "on" after "checking whether policy is enabled"?)

psql does already have that labeling according to "ls -Z",
so unsurprisingly, the recommended remediation doesn't help.

Trying to drill down a bit, I did what the script is doing:

$ runcon -t sepgsql_regtest_user_t psql --help
psql: fatal: could not look up effective user ID 1000: user does not exist

But uid 1000 is me according to /etc/passwd and according to "id":

$ id
uid=1000(tgl) gid=1000(tgl) groups=1000(tgl),10(wheel) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

so there's nothing much wrong with having that as euid.

I speculate that the policy is forbidding sepgsql_regtest_user_t
from reading /etc/passwd.  Perhaps this is fallout from the
compile problems reported for the policy module?  But I'm way
out of my depth here.

I'm pretty sure the test recipe last worked for me on F28.
Off to try F29.

            regards, tom lane