From: Tom Lane <tgl@sss.pgh.pa.us>
To: Mike Palmiotto <mike.palmiotto@crunchydata.com>
cc: pgsql-hackers@lists.postgresql.org, Joe Conway <mail@joeconway.com>
Subject: Re: sepgsql seems rather thoroughly broken on Fedora 30
In-reply-to: 
 <CAMN686F4MiHK9qn_CnNk4X1iDjFGDU8h6kb7iVCtbN4NEOVDwg@mail.gmail.com>
References: <23856.1563381159@sss.pgh.pa.us>
 <CAMN686Ew55FmGAZMsin_r2GKOpTwNwGS2PJ2v+KX8jO2yU3Sqw@mail.gmail.com>
 <29576.1563505591@sss.pgh.pa.us>
 <CAMN686F4MiHK9qn_CnNk4X1iDjFGDU8h6kb7iVCtbN4NEOVDwg@mail.gmail.com>
Comments: In-reply-to Mike Palmiotto <mike.palmiotto@crunchydata.com>
	message dated "Fri, 19 Jul 2019 09:37:45 -0400"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <24919.1563548625.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Fri, 19 Jul 2019 11:03:45 -0400
Message-ID: <24920.1563548625@sss.pgh.pa.us>
Precedence: bulk

Mike Palmiotto <mike.palmiotto@crunchydata.com> writes:
> On Thu, Jul 18, 2019 at 11:06 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 e=
xist

> 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

It's definitely SELinux.  The grep finds entries like

type=3DAVC msg=3Daudit(1563547268.044:465): avc:  denied  { read } for  pi=
d=3D10940 comm=3D"psql" name=3D"passwd" dev=3D"sda6" ino=3D4721184 scontex=
t=3Dunconfined_u:unconfined_r:sepgsql_regtest_user_t:s0-s0:c0.c1023 tconte=
xt=3Dsystem_u:object_r:passwd_file_t:s0 tclass=3Dfile permissive=3D0

which audit2allow turns into

#=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D sepgsql_regtest_user_t =3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
allow sepgsql_regtest_user_t passwd_file_t:file read;

So somehow, my system's interpretation of the test policy file does
not include that permission.

I tried:

* restorecon / ... no effect, which is unsurprising given that /etc/passwd
was OK already.

* removing container-selinux ... this made the compile warnings go away,
as you predicted, but no change in the test results.

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

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

Well, that's just weird.  I've not done anything to the SELinux state
on this installation either, so what's different?

I am wondering whether maybe the different behavior is a result of some
RPM that's present on my system but not yours, or vice versa.  As
a first stab at that, I see:

$ rpm -qa | grep selinux | sort
cockpit-selinux-198-1.fc30.noarch
container-selinux-2.107-1.git453b816.fc30.noarch
flatpak-selinux-1.4.2-2.fc30.x86_64
libselinux-2.9-1.fc30.x86_64
libselinux-devel-2.9-1.fc30.x86_64
libselinux-utils-2.9-1.fc30.x86_64
python3-libselinux-2.9-1.fc30.x86_64
rpm-plugin-selinux-4.14.2.1-4.fc30.1.x86_64
selinux-policy-3.14.3-40.fc30.noarch
selinux-policy-devel-3.14.3-40.fc30.noarch
selinux-policy-targeted-3.14.3-40.fc30.noarch
tpm2-abrmd-selinux-2.0.0-4.fc30.noarch

			regards, tom lane