From: | Joe Conway <mail(at)joeconway(dot)com> |
---|---|
To: | Yuli Khodorkovskiy <yuli(dot)khodorkovskiy(at)crunchydata(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Stephen Frost <sfrost(at)snowman(dot)net>, Kohei KaiGai <kaigai(at)heterodb(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org, Joshua Brindle <joshua(dot)brindle(at)crunchydata(dot)com>, Mike P <mike(dot)palmiotto(at)crunchydata(dot)com>, Joe Conway <joe(at)crunchydata(dot)com> |
Subject: | Re: add a MAC check for TRUNCATE |
Date: | 2019-09-06 20:31:46 |
Message-ID: | 59f95815-acb2-d7fb-34a6-dcdae64249ac@joeconway.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 9/6/19 2:13 PM, Yuli Khodorkovskiy wrote:
> As Joe Conway pointed out to me out of band, the build animal for RHEL
> 7 has handle_unknown set to `0`. Are there any other concerns with
> this approach?
You mean deny_unknown I believe.
"Allow unknown object class / permissions. This will set the returned AV
with all 1's."
As I understand it, this would make the sepgsql behavior unchanged from
before if the policy does not support the new permission.
Joe
> On Fri, Sep 6, 2019 at 1:00 PM Yuli Khodorkovskiy wrote:
>> The default SELinux policy on Fedora ships with deny_unknown set to 0.
>> Deny_unknown was added to the kernel in 2.6.24, so unless someone is
>> using RHEL 5.x, which is in ELS, they will have the ability to
>> override the default behavior on CentOS/RHEL.
--
Crunchy Data - http://crunchydata.com
PostgreSQL Support for Secure Enterprises
Consulting, Training, & Open Source Development
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Munro | 2019-09-06 20:40:53 | Re: ERROR: multixact X from before cutoff Y found to be still running |
Previous Message | Alvaro Herrera from 2ndQuadrant | 2019-09-06 19:54:34 | Re: SQL-spec incompatibilities in similar_escape() and related stuff |