On Thu, Feb 28, 2019 at 9:12 AM Robert Haas wrote:
Hi, Robert, it has been a while :)
>
> So... you're just going to replace ALL error messages of any kind with
> "ERROR: missing error text" when this option is enabled? That sounds
> unusable. I mean if I'm reading it right this would get not
On Thu, Feb 28, 2019 at 10:49 AM Tom Lane wrote:
>
> Joshua Brindle writes:
> > On Thu, Feb 28, 2019 at 9:12 AM Robert Haas wrote:
> >> So... you're just going to replace ALL error messages of any kind with
> >> "ERROR: missing error text" when this
On Thu, Feb 28, 2019 at 11:14 AM Joe Conway wrote:
>
> > Although, and Joe may hate me for saying this, I think only the
> > non-constants should be redacted to keep some level of usability for
> > regular SQL errors. Maybe system errors like the above should be
> > removed from client messages in
On Wed, Aug 28, 2019 at 1:42 PM Tom Lane wrote:
>
> Peter Eisentraut writes:
> > On 2019-08-28 17:13, Joe Conway wrote:
> >> Attached is a patch for discussion, adding support for seccomp-bpf
> >> (nowadays generally just called seccomp) syscall filtering at
> >> configure-time using libseccomp.
On Wed, Aug 28, 2019 at 2:47 PM Joshua Brindle
wrote:
>
> On Wed, Aug 28, 2019 at 2:30 PM Tom Lane wrote:
> >
>
> >
> > (And, TBH, I'm still wondering why SELinux isn't the way to address this.)
>
> Just going to address this one now. SELinux is an LS
On Wed, Aug 28, 2019 at 2:30 PM Tom Lane wrote:
>
>
> (And, TBH, I'm still wondering why SELinux isn't the way to address this.)
Just going to address this one now. SELinux is an LSM and therefore
only makes decisions when LSM hooks are invoked, which are not 1:1 for
syscalls (not even close). F
On Wed, Aug 28, 2019 at 2:53 PM Andres Freund wrote:
>
> Hi,
>
> On 2019-08-28 14:47:04 -0400, Joshua Brindle wrote:
> > A prime example is madvise() which was a catastrophic failure that 1)
> > isn't preventable by any LSM including SELinux, 2) isn't used
On Wed, Aug 28, 2019 at 3:22 PM Andres Freund wrote:
>
> Hi,
>
> On 2019-08-28 15:02:17 -0400, Joshua Brindle wrote:
> > On Wed, Aug 28, 2019 at 2:53 PM Andres Freund wrote:
> > > On 2019-08-28 14:47:04 -0400, Joshua Brindle wrote:
> > > > A prime exampl
On Thu, Aug 29, 2019 at 10:01 AM Tom Lane wrote:
>
> Joe Conway writes:
> > Clearly Joshua and I disagree, but understand that the consensus is not
> > on our side. It is our assessment that PostgreSQL will be subject to
> > seccomp willingly or not (e.g., via docker, systemd, etc.) and the
> > c
On Thu, Feb 28, 2019 at 9:12 AM Robert Haas wrote:
Hi, Robert, it has been a while :)
>
> So... you're just going to replace ALL error messages of any kind with
> "ERROR: missing error text" when this option is enabled? That sounds
> unusable. I mean if I'm reading it right this would get not
On Thu, Feb 28, 2019 at 10:49 AM Tom Lane wrote:
>
> Joshua Brindle writes:
> > On Thu, Feb 28, 2019 at 9:12 AM Robert Haas wrote:
> >> So... you're just going to replace ALL error messages of any kind with
> >> "ERROR: missing error text" when this
On Thu, Feb 28, 2019 at 11:14 AM Joe Conway wrote:
>
> > Although, and Joe may hate me for saying this, I think only the
> > non-constants should be redacted to keep some level of usability for
> > regular SQL errors. Maybe system errors like the above should be
> > removed from client messages in
On Mon, Nov 8, 2021 at 3:44 PM Stephen Frost wrote:
>
> Greetings,
>
> * Joshua Brindle (joshua.brin...@crunchydata.com) wrote:
> > On Wed, Oct 27, 2021 at 5:20 PM Joshua Brindle
> > wrote:
> > > On Wed, Oct 27, 2021 at 5:16 PM Robert Haas wrote:
> > >
On Fri, Nov 5, 2021 at 6:01 AM Daniel Gustafsson wrote:
>
> Attached is a rebase fixing a tiny bug in the documentation which prevented it
> from being able to compile.
>
Hello, I'm looking to help out with reviews for this CF and I'm
currently looking at this patchset.
currently I'm stuck tryin
On Tue, Nov 9, 2021 at 1:59 PM Joshua Brindle
wrote:
>
> On Fri, Nov 5, 2021 at 6:01 AM Daniel Gustafsson wrote:
> >
> > Attached is a rebase fixing a tiny bug in the documentation which prevented
> > it
> > from being able to compile.
> >
>
> Hello
On Tue, Nov 9, 2021 at 2:02 PM Joshua Brindle
wrote:
>
> On Tue, Nov 9, 2021 at 1:59 PM Joshua Brindle
> wrote:
> >
> > On Fri, Nov 5, 2021 at 6:01 AM Daniel Gustafsson wrote:
> > >
> > > Attached is a rebase fixing a tiny bug in the documentation which
&
On Wed, Nov 10, 2021 at 12:45 PM Bossart, Nathan wrote:
>
> On 11/8/21, 2:19 PM, "Joshua Brindle" wrote:
> > Thanks for the review, attached is an update with that comment fixed
> > and also sgml documentation changes that I missed earlier.
>
> I think there are
On Wed, Nov 10, 2021 at 8:49 AM Daniel Gustafsson wrote:
>
> > On 9 Nov 2021, at 22:22, Joshua Brindle
> > wrote:
> > On Tue, Nov 9, 2021 at 2:02 PM Joshua Brindle
> > wrote:
> >>
> >> On Tue, Nov 9, 2021 at 1:59 PM Joshua Brindle
> >&g
On Mon, Nov 15, 2021 at 4:44 PM Daniel Gustafsson wrote:
>
> > On 15 Nov 2021, at 20:51, Joshua Brindle
> > wrote:
>
> > Apologies for the delay, this didn't go to my inbox and I missed it on list.
> >
> > The bitcode generation is still broken, th
On Mon, Nov 15, 2021 at 5:37 PM Joshua Brindle
wrote:
>
> On Mon, Nov 15, 2021 at 4:44 PM Daniel Gustafsson wrote:
> >
> > > On 15 Nov 2021, at 20:51, Joshua Brindle
> > > wrote:
> >
> > > Apologies for the delay, this didn't go to my inb
On Tue, Nov 16, 2021 at 9:45 AM Joshua Brindle
wrote:
>
> On Mon, Nov 15, 2021 at 5:37 PM Joshua Brindle
> wrote:
> >
> > On Mon, Nov 15, 2021 at 4:44 PM Daniel Gustafsson wrote:
> > >
> > > > On 15 Nov 2021, at 20:51, Joshua Brindle
> > > &g
On Tue, Nov 16, 2021 at 1:26 PM Joshua Brindle
wrote:
>
> On Tue, Nov 16, 2021 at 9:45 AM Joshua Brindle
> wrote:
> >
> > On Mon, Nov 15, 2021 at 5:37 PM Joshua Brindle
> > wrote:
> > >
> > > On Mon, Nov 15, 2021 at 4:44 PM Daniel Gustafsson wrot
On Tue, Nov 23, 2021 at 9:12 AM Daniel Gustafsson wrote:
>
> > On 17 Nov 2021, at 19:42, Joshua Brindle
> > wrote:
> > On Tue, Nov 16, 2021 at 1:26 PM Joshua Brindle
> > wrote:
>
> >> I think there it a typo in the docs here that prevents them from
&
On Wed, Nov 24, 2021 at 6:59 AM Daniel Gustafsson wrote:
>
> > On 23 Nov 2021, at 23:39, Joshua Brindle
> > wrote:
>
> > It no longer happens with v49, since it was a null deref of the pr_fd
> > which no longer happens.
> >
> > I'll continue tes
On Wed, Nov 24, 2021 at 8:46 AM Joshua Brindle
wrote:
>
> On Wed, Nov 24, 2021 at 6:59 AM Daniel Gustafsson wrote:
> >
> > > On 23 Nov 2021, at 23:39, Joshua Brindle
> > > wrote:
> >
> > > It no longer happens with v49, since it was a null der
On Wed, Nov 24, 2021 at 8:49 AM Joshua Brindle
wrote:
>
> On Wed, Nov 24, 2021 at 8:46 AM Joshua Brindle
> wrote:
> >
> > On Wed, Nov 24, 2021 at 6:59 AM Daniel Gustafsson wrote:
> > >
> > > > On 23 Nov 2021, at 23:39, Joshua Brindle
> > > &g
On Mon, Dec 13, 2021 at 5:34 PM Mark Dilger
wrote:
>
>
>
> > On Dec 13, 2021, at 1:33 PM, Mark Dilger
> > wrote:
> >
> > but will repost in a few hours
>
> ... and here it is:
currently there is a failure in check-world (not sure if it's known):
diff -U3 /src/postgres/src/test/regress/expected
On Wed, Dec 15, 2021 at 10:56 AM Mark Dilger
wrote:
>
>
>
> > On Dec 14, 2021, at 2:26 PM, Joshua Brindle
> > wrote:
> >
> > currently there is a failure in check-world (not sure if it's known):
>
> That one is definitely my fault. 'en_US.UTF
On Wed, Dec 15, 2021 at 1:18 PM Mark Dilger
wrote:
>
> > On Dec 15, 2021, at 10:02 AM, Joshua Brindle
> > wrote:
> >
> > Ah, I was actually requesting a hook where the acl check was done for
> > setting a GUC, such that we could deny setting them in a hook,
&
On Thu, Dec 16, 2021 at 12:53 PM Mark Dilger
wrote:
>
>
>
> > On Dec 16, 2021, at 7:43 AM, Joshua Brindle
> > wrote:
> >
> > Ah, I understand now. Would it be possible to pass the
> > SettingAclRelationId if it exists or InvalidOid if not?
>
> Sett
On Wed, Dec 15, 2021 at 5:05 PM Daniel Gustafsson wrote:
>
> > On 25 Nov 2021, at 14:39, Joshua Brindle
> > wrote:
> > On Wed, Nov 24, 2021 at 8:49 AM Joshua Brindle
> > wrote:
> >>
> >> On Wed, Nov 24, 2021 at 8:46 AM Joshua Brindle
> >>
On Tue, Dec 21, 2021 at 8:26 PM Mark Dilger
wrote:
>
>
>
> > On Dec 21, 2021, at 5:11 PM, Shinya Kato
> > wrote:
> >
> > I fixed the patches because they cannot be applied to HEAD.
>
> Thank you.
I reviewed and tested these and they LGTM. FYI the rebased v3 patches
upthread are raw diffs so git
user
--
brindle
(1 row)
postgres=> SHOW config_file;
config_file
---
/var/lib/pgsql/15/postgresql.conf
(1 row)
Signed-off-by: Joshua Brindle
---
src/backend/commands/copy.c | 12 ++--
src/backend/replication/wal
As a follow-on to Conflation of member/privs for predefined roles,
this removes is_member_of_role from the header to dissuade it's use
for privilege checking. Since SET ROLE must use membership rather than
privileges a new, explicitly named can_set_role() function is
exported.
is_member_of_role_no
On Wed, Oct 27, 2021 at 1:12 PM Mark Dilger
wrote:
>
>
>
> > On Oct 27, 2021, at 9:26 AM, Joshua Brindle
> > wrote:
> >
> > As a follow-on to Conflation of member/privs for predefined roles,
> > this removes is_member_of_role from the header to dissu
On Wed, Oct 27, 2021 at 1:20 PM Bossart, Nathan wrote:
>
> On 10/26/21, 3:50 PM, "Joshua Brindle" wrote:
> > Generally if a role is granted membership to another role with NOINHERIT
> > they must use SET ROLE to access the privileges of that role, however
> > wi
On Wed, Oct 27, 2021 at 1:34 PM Bossart, Nathan wrote:
>
> On 10/27/21, 10:28 AM, "Joshua Brindle"
> wrote:
> > I'm new to contributing here but I've been told that the string
> > changes get taken care of later, is that not true?
>
> I will someti
Attached is an updated version of the patch to replace
is_member_of_role with has_privs_for_role for predefined roles. It
does not remove is_member_of_role from acl.h but it does add a warning
not to use that function for privilege checking.
Please consider this for the upcoming commitfest.
0001
On Wed, Oct 27, 2021 at 5:16 PM Robert Haas wrote:
>
> On Wed, Oct 27, 2021 at 5:14 PM Joshua Brindle
> wrote:
> > Attached is an updated version of the patch to replace
> > is_member_of_role with has_privs_for_role for predefined roles. It
> > does not remove is_membe
On Wed, Oct 27, 2021 at 5:20 PM Joshua Brindle
wrote:
>
> On Wed, Oct 27, 2021 at 5:16 PM Robert Haas wrote:
> >
> > On Wed, Oct 27, 2021 at 5:14 PM Joshua Brindle
> > wrote:
> > > Attached is an updated version of the patch to replace
> > > is_
On Thu, Mar 17, 2022 at 11:21 PM Mark Dilger
wrote:
>
> Hackers,
>
> Over in [1], Joshua proposed a new set of Object Access Type hooks based on
> strings rather than Oids.
>
> His patch was written to be applied atop my patch for granting privileges on
> gucs.
>
> On review of his patch, I beca
On Sun, Mar 20, 2022 at 12:27 PM Joe Conway wrote:
>
> On 3/3/22 11:26, Joshua Brindle wrote:
> > On Thu, Feb 10, 2022 at 2:37 PM Joe Conway wrote:
> >>
> >> On 2/10/22 14:28, Nathan Bossart wrote:
> >> > On Wed, Feb 09, 2022 at 04:39:11PM -0500, Joe Con
On Sun, Mar 20, 2022 at 12:34 PM Joe Conway wrote:
>
> On 3/20/22 12:31, Joshua Brindle wrote:
> > On Sun, Mar 20, 2022 at 12:27 PM Joe Conway wrote:
> >>
> >> On 3/3/22 11:26, Joshua Brindle wrote:
> >> > On Thu, Feb 10, 2022 at 2:37 PM Joe Conwa
On Wed, Mar 30, 2022 at 12:00 AM Mark Dilger
wrote:
>
> > On Mar 28, 2022, at 3:31 PM, Tom Lane wrote:
> >
> > This is what I meant by saying that you can't just refuse to GRANT on
> > unknown GUCs. It makes custom GUCs into a time bomb for dump/restore.
> > And that means you need a strategy fo
On Fri, Apr 1, 2022 at 6:06 PM Nathan Bossart wrote:
>
> Hi hackers,
>
> 6198420 ensured that has_privs_of_role() is used for predefined roles,
> which means that the role inheritance hierarchy is checked instead of mere
> role membership. However, inheritance is still not respected for
> pg_hba.
On Wed, Aug 28, 2019 at 1:42 PM Tom Lane wrote:
>
> Peter Eisentraut writes:
> > On 2019-08-28 17:13, Joe Conway wrote:
> >> Attached is a patch for discussion, adding support for seccomp-bpf
> >> (nowadays generally just called seccomp) syscall filtering at
> >> configure-time using libseccomp.
On Wed, Aug 28, 2019 at 2:47 PM Joshua Brindle
wrote:
>
> On Wed, Aug 28, 2019 at 2:30 PM Tom Lane wrote:
> >
>
> >
> > (And, TBH, I'm still wondering why SELinux isn't the way to address this.)
>
> Just going to address this one now. SELinux is an LS
On Wed, Aug 28, 2019 at 2:30 PM Tom Lane wrote:
>
>
> (And, TBH, I'm still wondering why SELinux isn't the way to address this.)
Just going to address this one now. SELinux is an LSM and therefore
only makes decisions when LSM hooks are invoked, which are not 1:1 for
syscalls (not even close). F
On Wed, Aug 28, 2019 at 2:53 PM Andres Freund wrote:
>
> Hi,
>
> On 2019-08-28 14:47:04 -0400, Joshua Brindle wrote:
> > A prime example is madvise() which was a catastrophic failure that 1)
> > isn't preventable by any LSM including SELinux, 2) isn't used
On Wed, Aug 28, 2019 at 3:22 PM Andres Freund wrote:
>
> Hi,
>
> On 2019-08-28 15:02:17 -0400, Joshua Brindle wrote:
> > On Wed, Aug 28, 2019 at 2:53 PM Andres Freund wrote:
> > > On 2019-08-28 14:47:04 -0400, Joshua Brindle wrote:
> > > > A prime exampl
On Thu, Aug 29, 2019 at 10:01 AM Tom Lane wrote:
>
> Joe Conway writes:
> > Clearly Joshua and I disagree, but understand that the consensus is not
> > on our side. It is our assessment that PostgreSQL will be subject to
> > seccomp willingly or not (e.g., via docker, systemd, etc.) and the
> > c
On Mon, Jan 3, 2022 at 5:08 PM Andrew Dunstan wrote:
>
>
> On 12/23/21 16:06, Joshua Brindle wrote:
> > On Tue, Dec 21, 2021 at 8:26 PM Mark Dilger
> > wrote:
> >>
> >>
> >>> On Dec 21, 2021, at 5:11 PM, Shinya Kato
> >>> wrote:
&g
On Tue, Jan 4, 2022 at 3:39 PM Mark Dilger wrote:
>
>
>
> > On Jan 4, 2022, at 9:07 AM, Mark Dilger
> > wrote:
> >
> > No, that looks like a bug.
>
> I was able to reproduce that using REASSIGN OWNED BY to cause a user to own
> itself. Is that how you did it, or is there yet another way to get
On Tue, Jan 4, 2022 at 3:56 PM Tom Lane wrote:
>
> "Bossart, Nathan" writes:
> > On 11/12/21, 12:34 PM, "Joshua Brindle"
> > wrote:
> >> All of these and also adminpack.sgml updated. I think that is all of
> >> them but docs broken ac
On Wed, Jan 5, 2022 at 7:05 PM Mark Dilger wrote:
> > On Jan 4, 2022, at 12:47 PM, Joshua Brindle
> > wrote:
> >
> >> I was able to reproduce that using REASSIGN OWNED BY to cause a user to
> >> own itself. Is that how you did it, or is there yet anot
On Tue, Jan 18, 2022 at 7:43 AM Daniel Gustafsson wrote:
>
> > On 18 Jan 2022, at 07:36, Julien Rouhaud wrote:
>
> > On Mon, Jan 17, 2022 at 03:09:11PM +0100, Daniel Gustafsson wrote:
> >>
> >> I must've fat-fingered the "git add -p" for v50 as the fix was in
> >> configure.ac
> >> but not confi
On Mon, Jan 31, 2022 at 1:50 PM Stephen Frost wrote:
>
> Greetings,
>
> * Mark Dilger (mark.dil...@enterprisedb.com) wrote:
> > > On Jan 31, 2022, at 8:53 AM, Stephen Frost wrote:
> > > Yeah, we do need to have a way to determine who is allowed to drop
> > > roles and role ownership seems like it
On Mon, Feb 7, 2022 at 12:09 PM Robert Haas wrote:
>
> On Mon, Feb 7, 2022 at 11:13 AM Joe Conway wrote:
> > Easily worked around with one additional level of role:
>
> Interesting.
>
> > > But in the absence of that, it seems clearly better for predefined
> > > roles to disregard INHERIT and jus
On Tue, Feb 8, 2022 at 8:46 AM Robert Haas wrote:
>
> On Tue, Feb 8, 2022 at 6:59 AM Joe Conway wrote:
> > This is similar to bob's access to the default superuser privilege to
> > read data in someone else's table (must SET ROLE to access that capability).
> >
> > But it is different from bob's
On Wed, Feb 9, 2022 at 3:58 PM Robert Haas wrote:
>
> On Wed, Feb 9, 2022 at 1:13 PM Nathan Bossart
> wrote:
> > I do wonder if users find the differences between predefined roles and role
> > attributes confusing. INHERIT doesn't govern role attributes, but it will
> > govern predefined roles
On Thu, Feb 17, 2022 at 12:40 PM Robert Haas wrote:
>
> On Mon, Jan 31, 2022 at 1:57 PM Joshua Brindle
> wrote:
> > This is precisely the use case I am trying to accomplish with this
> > patchset, roughly:
> >
> > - An automated bot that creates users an
On Wed, Mar 2, 2022 at 9:58 AM Joshua Brindle
wrote:
>
> This is not intended for PG15.
>
> Attached are a proof of concept patchset to implement multiple valid
> passwords, which have independent expirations, set by a GUC or SQL
> using an interval.
>
>
On Wed, Mar 2, 2022 at 10:29 AM Stephen Frost wrote:
>
> Greetings,
>
> * Bruce Momjian (br...@momjian.us) wrote:
> > On Wed, Mar 2, 2022 at 10:09:31AM -0500, Stephen Frost wrote:
> > > I'm not sure that it's quite so simple. Perhaps we should also drop
> > > LDAP and I don't really think PAM wa
On Thu, Mar 3, 2022 at 4:45 AM Peter Eisentraut
wrote:
>
> On 02.03.22 16:45, Jonathan S. Katz wrote:
> > By that argument, we should have kept "password" (plain) as an
> > authentication method.
>
> For comparison, the time between adding md5 and removing password was 16
> years. It has been 5 y
On Thu, Feb 10, 2022 at 2:37 PM Joe Conway wrote:
>
> On 2/10/22 14:28, Nathan Bossart wrote:
> > On Wed, Feb 09, 2022 at 04:39:11PM -0500, Joe Conway wrote:
> >> On 2/9/22 13:13, Nathan Bossart wrote:
> >>> I do wonder if users find the differences between predefined roles and
> >>> role
> >>> a
On Thu, Mar 3, 2022 at 11:50 PM Tatsuo Ishii wrote:
>
> >> So, dropping plaintext password authentication support from libpq will
> >> make it impossible for users to use the former method.
> >
> > Yes, just like dropping support for md5 would make it impossible for
> > users to have their passwor
On Sun, Mar 6, 2022 at 10:19 AM Robert Haas wrote:
>
> On Fri, Mar 4, 2022 at 5:20 PM David G. Johnston
> wrote:
> > I think I disagree. Or, at least, the superuser has full control of
> > dictating how role membership is modified and that seems sufficient.
>
> The point is that the superuser D
On Fri, Mar 4, 2022 at 6:03 PM Tatsuo Ishii wrote:
>
> >> I still don't understand why using plaintex password authentication
> >> over SSL connection is considered insecure. Actually we have been
> >> stating opposite in the manual:
> >> https://www.postgresql.org/docs/14/auth-password.html
> >>
On Thu, Mar 10, 2022 at 12:11 PM Robert Haas wrote:
>
> On Thu, Mar 10, 2022 at 11:19 AM Stephen Frost wrote:
> > I disagree that ownership is needed that's not what the spec calls for
> > either. What we need is more flexibility when it comes to the
> > relationships which are allowed to be cre
> I suggest that what might be saner is to consider that the "objects"
> that the hook calls are concerned with are the pg_setting_acl entries,
> not the underlying GUCs, and thus that the hooks need be invoked only
> when creating, destroying or altering those entries. If we do have
> a need fo
On Wed, Mar 16, 2022 at 3:06 PM Tom Lane wrote:
>
> Mark Dilger writes:
> > On Mar 16, 2022, at 11:47 AM, Tom Lane wrote:
> >> ... I therefore judge the
> >> hook calls added to ExecSetVariableStmt and AlterSystemSetConfigFile
> >> to be 100% useless, in fact probably counterproductive because t
> I remain of the opinion that this
> patch should not concern itself with that, though.
So you are saying that people can add new object types to PG with DAC
permissions and not concern themselves with MAC capable hooks? Is that
an official PG community stance?
On Thu, Mar 17, 2022 at 12:04 PM Robert Haas wrote:
>
> On Thu, Mar 17, 2022 at 9:25 AM Joshua Brindle
> wrote:
> >
> >
> > > I remain of the opinion that this
> > > patch should not concern itself with that, though.
> >
> > So you are saying
On Thu, Mar 17, 2022 at 12:36 PM Mark Dilger
wrote:
> > On Mar 17, 2022, at 9:29 AM, Joshua Brindle
> > wrote:
> >
> > I hope this patch can be rolled
> > into the contribution from Mark.
>
> Working on it Thanks for the patch!
Great, than
74 matches
Mail list logo
