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
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 |