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

From Tom Lane
Subject Re: sepgsql seems rather thoroughly broken on Fedora 30
Date
Msg-id 24920.1563548625@sss.pgh.pa.us
Whole thread Raw
In response to Re: sepgsql seems rather thoroughly broken on Fedora 30  (Mike Palmiotto <mike.palmiotto@crunchydata.com>)
List pgsql-hackers
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 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

It's definitely SELinux.  The grep finds entries like

type=AVC msg=audit(1563547268.044:465): avc:  denied  { read } for  pid=10940 comm="psql" name="passwd" dev="sda6"
ino=4721184scontext=unconfined_u:unconfined_r:sepgsql_regtest_user_t:s0-s0:c0.c1023
tcontext=system_u:object_r:passwd_file_t:s0tclass=file permissive=0 

which audit2allow turns into

#============= sepgsql_regtest_user_t ==============
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



pgsql-hackers by date:

Previous
From: Liudmila Mantrova
Date:
Subject: Re: Support for jsonpath .datetime() method
Next
From: Tom Lane
Date:
Subject: Re: sepgsql seems rather thoroughly broken on Fedora 30