On 11/22/19 3:07 AM, Michael Paquier wrote:
> On Wed, Nov 20, 2019 at 02:30:12PM -0500, Joe Conway wrote:
>> I tested this successfully on Rhinoceros, both with and without
>> "db_table: { truncate }" loaded in the policy. Updated patches attached
>> here with some editorialization. If there are no
On Wed, Nov 20, 2019 at 02:30:12PM -0500, Joe Conway wrote:
> I tested this successfully on Rhinoceros, both with and without
> "db_table: { truncate }" loaded in the policy. Updated patches attached
> here with some editorialization. If there are no objections I will
> commit/push both in about a
On 11/20/19 2:30 PM, Joe Conway wrote:
> On 11/8/19 9:16 AM, Joe Conway wrote:
>> On 11/8/19 9:02 AM, Yuli Khodorkovskiy wrote:
>>> On Thu, Nov 7, 2019 at 7:46 PM Michael Paquier wrote:
On Mon, Sep 30, 2019 at 11:38:05AM -0300, Alvaro Herrera wrote:
> On 2019-Sep-30, Joe Conway wrot
On 11/8/19 9:16 AM, Joe Conway wrote:
> On 11/8/19 9:02 AM, Yuli Khodorkovskiy wrote:
>> On Thu, Nov 7, 2019 at 7:46 PM Michael Paquier wrote:
>>>
>>> On Mon, Sep 30, 2019 at 11:38:05AM -0300, Alvaro Herrera wrote:
>>> > On 2019-Sep-30, Joe Conway wrote:
>>> >
>>> > > I am not sure I will get to t
On 11/8/19 9:02 AM, Yuli Khodorkovskiy wrote:
> On Thu, Nov 7, 2019 at 7:46 PM Michael Paquier wrote:
>>
>> On Mon, Sep 30, 2019 at 11:38:05AM -0300, Alvaro Herrera wrote:
>> > On 2019-Sep-30, Joe Conway wrote:
>> >
>> > > I am not sure I will get to this today. I assume it is ok for me to move
>>
On Thu, Nov 7, 2019 at 7:46 PM Michael Paquier wrote:
>
> On Mon, Sep 30, 2019 at 11:38:05AM -0300, Alvaro Herrera wrote:
> > On 2019-Sep-30, Joe Conway wrote:
> >
> > > I am not sure I will get to this today. I assume it is ok for me to move
> > > it forward e.g. next weekend, or is that not in l
On Mon, Sep 30, 2019 at 11:38:05AM -0300, Alvaro Herrera wrote:
> On 2019-Sep-30, Joe Conway wrote:
>
> > I am not sure I will get to this today. I assume it is ok for me to move
> > it forward e.g. next weekend, or is that not in line with commitfest rules?
>
> You can commit whatever patch when
On 2019-Sep-30, Joe Conway wrote:
> I am not sure I will get to this today. I assume it is ok for me to move
> it forward e.g. next weekend, or is that not in line with commitfest rules?
You can commit whatever patch whenever you feel like it. I will
probably move this patch to the next commitfe
On 9/25/19 4:47 PM, Joe Conway wrote:
> On 9/25/19 3:56 PM, Alvaro Herrera wrote:
>> Hello
>>
>> On 2019-Sep-09, Yuli Khodorkovskiy wrote:
>>
>>> I have included an updated version of the sepgql patch. The
>>> Truncate-Hook patch is unchanged from the last version.
>>
>> This patch no longer app
On Wed, Sep 25, 2019 at 5:57 PM Tom Lane wrote:
> I don't see how the addition of a new permissions check could sanely
> be back-patched unless it were to default to "allow", which seems like
> an odd choice.
>
> regards, tom lane
That makes sense. Alternatively, we coul
Alvaro Herrera writes:
> On 2019-Sep-25, Yuli Khodorkovskiy wrote:
>> Since all existing DAC checks should have MAC, should these patches be
>> considered a bug fix and therefore back patched?
> I don't know the answer to that. My impression from earlier discussion
> is that this was seen as a n
On 2019-Sep-25, Yuli Khodorkovskiy wrote:
> Hi Alvaro,
>
> I have attached the updated patches which should rebase.
Great, thanks.
> Since all existing DAC checks should have MAC, should these patches be
> considered a bug fix and therefore back patched?
I don't know the answer to that. My im
On Wed, Sep 25, 2019 at 3:57 PM Alvaro Herrera wrote:
>
> Hello
>
> On 2019-Sep-09, Yuli Khodorkovskiy wrote:
>
> > I have included an updated version of the sepgql patch. The
> > Truncate-Hook patch is unchanged from the last version.
>
> This patch no longer applies. Can you please rebase?
Hi
On 9/25/19 3:56 PM, Alvaro Herrera wrote:
> Hello
>
> On 2019-Sep-09, Yuli Khodorkovskiy wrote:
>
>> I have included an updated version of the sepgql patch. The
>> Truncate-Hook patch is unchanged from the last version.
>
> This patch no longer applies. Can you please rebase?
>
> Joe, do you p
Hello
On 2019-Sep-09, Yuli Khodorkovskiy wrote:
> I have included an updated version of the sepgql patch. The
> Truncate-Hook patch is unchanged from the last version.
This patch no longer applies. Can you please rebase?
Joe, do you plan on being committer for this patch? There seems to be
su
Hello,
I moved this patch from "Bug Fixes" to Security.
Thanks,
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Fri, Sep 6, 2019 at 9:09 PM Joe Conway wrote:
>
> On 9/6/19 8:07 PM, Tom Lane wrote:
> > Joe Conway writes:
> >> On 9/6/19 2:18 PM, Tom Lane wrote:
> >>> sepgsql hasn't worked on RHEL6 in a long time, if ever; it requires
> >>> a newer version of libselinux than what ships in RHEL6. So I'm no
On 9/6/19 8:07 PM, Tom Lane wrote:
> Joe Conway writes:
>> On 9/6/19 2:18 PM, Tom Lane wrote:
>>> sepgsql hasn't worked on RHEL6 in a long time, if ever; it requires
>>> a newer version of libselinux than what ships in RHEL6. So I'm not
>>> concerned about that. We do need to worry about RHEL7,
Joe Conway writes:
> On 9/6/19 2:18 PM, Tom Lane wrote:
>> sepgsql hasn't worked on RHEL6 in a long time, if ever; it requires
>> a newer version of libselinux than what ships in RHEL6. So I'm not
>> concerned about that. We do need to worry about RHEL7, and whatever
>> is the oldest version of
On Fri, Sep 6, 2019 at 4:31 PM Joe Conway wrote:
>
> 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 belie
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 th
On 9/6/19 2:18 PM, Tom Lane wrote:
> Yuli Khodorkovskiy writes:
>> On Fri, Sep 6, 2019 at 11:57 AM Tom Lane wrote:
>>> Well, the larger question, independent of the regression tests, is
>>> will the new policy work at all on older SELinux? If not, that
>>> doesn't seem very acceptable.
>
>> The
Yuli Khodorkovskiy writes:
> On Fri, Sep 6, 2019 at 11:57 AM Tom Lane wrote:
>> Well, the larger question, independent of the regression tests, is
>> will the new policy work at all on older SELinux? If not, that
>> doesn't seem very acceptable.
> The default SELinux policy on Fedora ships with
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?
On Fri, Sep 6, 2019 at 1:00 PM Yuli Khodorkovskiy
wrote:
>
> On Fri, Sep 6, 2019 at 11:57 AM Tom Lane wrote:
> >
> > Stephen Frost writes:
> >
On Fri, Sep 6, 2019 at 11:57 AM Tom Lane wrote:
>
> Stephen Frost writes:
> > * Tom Lane (t...@sss.pgh.pa.us) wrote:
> >> Yuli Khodorkovskiy writes:
> >>> 1) Get the sepgsql changes in without policy/regressions
> >>> 2) Send a patch to refpolicy for the new permission
> >>> 3) Once Redhat updat
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> Yuli Khodorkovskiy writes:
>>> 1) Get the sepgsql changes in without policy/regressions
>>> 2) Send a patch to refpolicy for the new permission
>>> 3) Once Redhat updates the selinux-policy-targeted RPM to include the
>>> new permi
On Fri, Sep 6, 2019 at 11:47 AM Tom Lane wrote:
>
> Yuli Khodorkovskiy writes:
> > Ah, now I remember why I didn't add regressions to the original patch.
> > As stated at the top of the thread, the "db_table: { truncate }"
> > permission does not currently exist in refpolicy. A workaround would
>
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Yuli Khodorkovskiy writes:
> > Ah, now I remember why I didn't add regressions to the original patch.
> > As stated at the top of the thread, the "db_table: { truncate }"
> > permission does not currently exist in refpolicy. A workaround would
>
Yuli Khodorkovskiy writes:
> Ah, now I remember why I didn't add regressions to the original patch.
> As stated at the top of the thread, the "db_table: { truncate }"
> permission does not currently exist in refpolicy. A workaround would
> be to add the policy with CIL, but that adds unneeded comp
On Fri, Sep 6, 2019 at 11:26 AM Yuli Khodorkovskiy
wrote:
>
> On Fri, Sep 6, 2019 at 10:40 AM Stephen Frost wrote:
> >
> > Greetings,
>
> Hello Stephen,
>
> >
> > * Yuli Khodorkovskiy (yuli.khodorkovs...@crunchydata.com) wrote:
> > > On Tue, Sep 3, 2019 at 3:25 PM Stephen Frost wrote:
> > > > *
On 9/6/19 11:26 AM, Yuli Khodorkovskiy wrote:
> On Fri, Sep 6, 2019 at 10:40 AM Stephen Frost wrote:
>> There are actual reasons why the 'DELETE' privilege is *not* the same as
>> 'TRUNCATE' in PostgreSQL and I'm really not convinced that we should
>> just be tossing that distinction out the windo
On Fri, Sep 6, 2019 at 10:40 AM Stephen Frost wrote:
>
> Greetings,
Hello Stephen,
>
> * Yuli Khodorkovskiy (yuli.khodorkovs...@crunchydata.com) wrote:
> > On Tue, Sep 3, 2019 at 3:25 PM Stephen Frost wrote:
> > > * Kohei KaiGai (kai...@heterodb.com) wrote:
> > > > 2019年7月25日(木) 3:52 Yuli Khodo
On Fri, Sep 6, 2019 at 10:40 AM Stephen Frost wrote:
> There are actual reasons why the 'DELETE' privilege is *not* the same as
> 'TRUNCATE' in PostgreSQL and I'm really not convinced that we should
> just be tossing that distinction out the window for users of SELinux.
+1.
--
Robert Haas
Enter
Greetings,
* Yuli Khodorkovskiy (yuli.khodorkovs...@crunchydata.com) wrote:
> On Tue, Sep 3, 2019 at 3:25 PM Stephen Frost wrote:
> > * Kohei KaiGai (kai...@heterodb.com) wrote:
> > > 2019年7月25日(木) 3:52 Yuli Khodorkovskiy
> > > :
> > > > Since all DAC checks should have corresponding MAC, this p
On Tue, Sep 3, 2019 at 3:25 PM Stephen Frost wrote:
>
> Greetings,
>
> * Kohei KaiGai (kai...@heterodb.com) wrote:
> > 2019年7月25日(木) 3:52 Yuli Khodorkovskiy :
> > > Since all DAC checks should have corresponding MAC, this patch adds a
> > > hook to allow extensions to implement a MAC check on TRUN
On Mon, Sep 2, 2019 at 10:58 AM Kohei KaiGai wrote:
>
> Hello Yuli,
Hello KaiGai,
>
> 2019年7月25日(木) 3:52 Yuli Khodorkovskiy :
> > Since all DAC checks should have corresponding MAC, this patch adds a
> > hook to allow extensions to implement a MAC check on TRUNCATE. I have
> > also implemented t
Greetings,
* Kohei KaiGai (kai...@heterodb.com) wrote:
> 2019年7月25日(木) 3:52 Yuli Khodorkovskiy :
> > Since all DAC checks should have corresponding MAC, this patch adds a
> > hook to allow extensions to implement a MAC check on TRUNCATE. I have
> > also implemented this access check in the sepgsql
Hello Yuli,
2019年7月25日(木) 3:52 Yuli Khodorkovskiy :
> Since all DAC checks should have corresponding MAC, this patch adds a
> hook to allow extensions to implement a MAC check on TRUNCATE. I have
> also implemented this access check in the sepgsql extension.
>
> One important thing to note is that
Hackers,
Since all DAC checks should have corresponding MAC, this patch adds a
hook to allow extensions to implement a MAC check on TRUNCATE. I have
also implemented this access check in the sepgsql extension.
One important thing to note is that refpolicy [1] and Redhat based
distributions do not
39 matches
Mail list logo
