Re: sepgsql seems rather thoroughly broken on Fedora 30

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Mike Palmiotto <mike(dot)palmiotto(at)crunchydata(dot)com>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org, Joe Conway <mail(at)joeconway(dot)com>
Subject: Re: sepgsql seems rather thoroughly broken on Fedora 30
Date: 2019-07-19 15:03:45
Message-ID: 24920.1563548625@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Mike Palmiotto <mike(dot)palmiotto(at)crunchydata(dot)com> writes:
> On Thu, Jul 18, 2019 at 11:06 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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=4721184 scontext=unconfined_u:unconfined_r:sepgsql_regtest_user_t:s0-s0:c0.c1023 tcontext=system_u:object_r:passwd_file_t:s0 tclass=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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2019-07-19 15:19:35 Re: sepgsql seems rather thoroughly broken on Fedora 30
Previous Message Liudmila Mantrova 2019-07-19 14:30:09 Re: Support for jsonpath .datetime() method