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 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
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 app
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 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?
>
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:
> >
> > Ste
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 refpolic
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
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
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:
>
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 ex
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 h
On Mon, Feb 25, 2019 at 5:25 PM Mike Palmiotto
wrote:
>
> On Mon, Feb 25, 2019 at 1:41 PM Mike Palmiotto
> wrote:
> >
> >
> > >
> > > If memory serves, StartChildProcess already was an attempt to unify
> > > the treatment of postmaster children. It's possible that another
> > > round of unifica
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
14 matches
Mail list logo