Greetings,
* Stephen Frost (sfr...@snowman.net) wrote:
> * Stephen Frost (sfr...@snowman.net) wrote:
> > * David Christensen (da...@pgguru.net) wrote:
> > > Ok, based on the interdiff there, I'm happy with that last change.
> > > Marking
> > > as Ready For Committer.
> >
> > Great, thanks!
> >
Greetings,
* Stephen Frost (sfr...@snowman.net) wrote:
> * David Christensen (da...@pgguru.net) wrote:
> > Ok, based on the interdiff there, I'm happy with that last change. Marking
> > as Ready For Committer.
>
> Great, thanks!
>
> I'm going to go through it again myself but I feel reasonably
Greetings,
* David Christensen (da...@pgguru.net) wrote:
> Ok, based on the interdiff there, I'm happy with that last change. Marking
> as Ready For Committer.
Great, thanks!
I'm going to go through it again myself but I feel reasonably good about
it and if nothing else pops and there aren't
Ok, based on the interdiff there, I'm happy with that last change. Marking
as Ready For Committer.
Best,
David
Greetings,
* David Christensen (da...@pgguru.net) wrote:
> Reviewed v8; largely looking good, though I notice this hunk, which may
> arguably be a bug fix, but doesn't appear to be relevant to this specific
> patch, so could probably be debated independently (and if a bug, should
> probably be
Reviewed v8; largely looking good, though I notice this hunk, which may
arguably be a bug fix, but doesn't appear to be relevant to this specific
patch, so could probably be debated independently (and if a bug, should
probably be backpatched):
diff --git a/contrib/postgres_fdw/option.c
Greetings,
* David Christensen (da...@pgguru.net) wrote:
> On Wed, Apr 5, 2023 at 3:30 PM Stephen Frost wrote:
> > Per GSS docs, seems like we should be comparing to GSS_C_NO_CREDENTIAL
> > and validating that the gflags has the `deleg_flag` bit set before
> > considering whether there are valid
On Wed, Apr 5, 2023 at 3:30 PM Stephen Frost wrote:
> Greetings,
>
> * David Christensen (david...@pgguru.net) wrote:
> > Did a code review pass here; here is some feedback.
>
> Thanks!
>
> > + /* If password was used to connect, make sure it was one provided
> */
> > + if
Greetings,
* David Christensen (david...@pgguru.net) wrote:
> Did a code review pass here; here is some feedback.
Thanks!
> + /* If password was used to connect, make sure it was one provided */
> + if (PQconnectionUsedPassword(conn) && dblink_connstr_has_pw(connstr))
> +
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: not tested
Documentation:not tested
Did a code review pass here; here is some feedback.
+ /* If
Greetings,
* Stephen Frost (sfr...@snowman.net) wrote:
> * Greg Stark (st...@mit.edu) wrote:
> > The CFBot says there's a function be_gssapi_get_proxy() which is
> > undefined. Presumably this is a missing #ifdef or a definition that
> > should be outside an #ifdef.
>
> Yup, just a couple of
Greetings,
* Greg Stark (st...@mit.edu) wrote:
> The CFBot says there's a function be_gssapi_get_proxy() which is
> undefined. Presumably this is a missing #ifdef or a definition that
> should be outside an #ifdef.
Yup, just a couple of missing #ifdef's.
Updated and rebased patch attached.
The CFBot says there's a function be_gssapi_get_proxy() which is
undefined. Presumably this is a missing #ifdef or a definition that
should be outside an #ifdef.
[14:05:21.532] dblink.c: In function ‘dblink_security_check’:
[14:05:21.532] dblink.c:2606:38: error: implicit declaration of
function
Greetings,
* Stephen Frost (sfr...@snowman.net) wrote:
> * Michael Paquier (mich...@paquier.xyz) wrote:
> > On Mon, Sep 19, 2022 at 02:05:39PM -0700, Jacob Champion wrote:
> > > It's not prevented, because a password is being used. In my tests I'm
> > > connecting as an unprivileged user.
> > >
Greetings,
* Michael Paquier (mich...@paquier.xyz) wrote:
> On Mon, Sep 19, 2022 at 02:05:39PM -0700, Jacob Champion wrote:
> > It's not prevented, because a password is being used. In my tests I'm
> > connecting as an unprivileged user.
> >
> > You're claiming that the middlebox shouldn't be
On Mon, Sep 19, 2022 at 02:05:39PM -0700, Jacob Champion wrote:
> It's not prevented, because a password is being used. In my tests I'm
> connecting as an unprivileged user.
>
> You're claiming that the middlebox shouldn't be doing this. If this new
> default behavior were the historical
On 9/19/22 10:05, Stephen Frost wrote:
> This is coming across as if it's a surprise of some kind when it
> certainly isn't.. If the delegated credentials are being used to
> authenticate and establish the connection from that backend to another
> system then, yes, naturally that means that the
Greetings,
* Jacob Champion (jchamp...@timescale.com) wrote:
> On Thu, Jul 7, 2022 at 4:24 PM Jacob Champion wrote:
> > So my question is this: does substituting my credentials for the admin's
> > credentials let me weaken or break the transport encryption on the
> > backend connection, and grab
On Thu, Jul 7, 2022 at 4:24 PM Jacob Champion wrote:
> So my question is this: does substituting my credentials for the admin's
> credentials let me weaken or break the transport encryption on the
> backend connection, and grab the password that I'm not supposed to have
> access to as a front-end
On 4/8/22 05:21, Stephen Frost wrote:
> Added a few more tests and updated the documentation too. Sadly, seems
> we've missed the deadline for v15 though for lack of feedback on these.
> Would really like to get some other folks commenting as these are new
> pg_hba and postgresql.conf options
On Fri, Apr 8, 2022 at 11:29 AM Stephen Frost wrote:
> > + allow_cred_delegation
> >
> > First, I again recommend not choosing words at random to abbreviate.
> > "delegate_credentials" would be shorter and clearer. Second, I think
> > we need to decide whether we envision just having one
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Fri, Apr 8, 2022 at 8:21 AM Stephen Frost wrote:
> > Added an explicit 'environment' option to allow for, basically, existing
> > behavior, where we don't mess with the environment variable at all,
> > though I kept the default as
On Fri, Apr 8, 2022 at 8:21 AM Stephen Frost wrote:
> Added an explicit 'environment' option to allow for, basically, existing
> behavior, where we don't mess with the environment variable at all,
> though I kept the default as MEMORY since I don't think it's really
> typical that folks actually
Greetings,
* Stephen Frost (sfr...@snowman.net) wrote:
> The new krb_user_ccache is a lot closer to 'global', though it's
> specifically for user-authenticated backends (allowing the postmaster
> and other things like replication connections to use whatever the
> credential cache is set to by the
Greetings,
* Stephen Frost (sfr...@snowman.net) wrote:
> * Jacob Champion (pchamp...@vmware.com) wrote:
> > On Fri, 2022-03-11 at 19:39 -0500, Stephen Frost wrote:
> > > Even so, I’m not against adding an option… but exactly how would that
> > > option be configured? Server level? On the HBA
Greetinsg,
* Jacob Champion (pchamp...@vmware.com) wrote:
> On Fri, 2022-03-11 at 19:39 -0500, Stephen Frost wrote:
> > On Fri, Mar 11, 2022 at 18:55 Jacob Champion wrote:
> > > [5] says we have to free the proxy credential with GSS_Release_cred();
> > > I don't see that happening anywhere, but
On Fri, 2022-03-11 at 19:39 -0500, Stephen Frost wrote:
>
> On Fri, Mar 11, 2022 at 18:55 Jacob Champion wrote:
> >
> > [5] says we have to free the proxy credential with GSS_Release_cred();
> > I don't see that happening anywhere, but I may have missed it.
>
> I’m not sure that it’s really
Greetings,
On Fri, Mar 11, 2022 at 18:55 Jacob Champion wrote:
> On Mon, 2022-02-28 at 20:28 -0500, Stephen Frost wrote:
> > Will add to the CF for consideration.
>
> GSSAPI newbie here, so caveat lector.
No worries, thanks for your interest!
> diff --git a/src/backend/libpq/auth.c
On Mon, 2022-02-28 at 20:28 -0500, Stephen Frost wrote:
> Will add to the CF for consideration.
GSSAPI newbie here, so caveat lector.
> diff --git a/src/backend/libpq/auth.c b/src/backend/libpq/auth.c
> index efc53f3135..6f820a34f1 100644
> --- a/src/backend/libpq/auth.c
> +++
Greetings,
(Dropping the original poster as their email address apparently no
longer works)
* Peter Eisentraut (peter.eisentr...@enterprisedb.com) wrote:
> On 22.07.21 10:39, Peifeng Qiu wrote:
> >I've slightly modified the patch to support "gssencmode" and added TAP
> >tests.
>
> For the TAP
> On 3 Nov 2021, at 13:41, Daniel Gustafsson wrote:
>
> This patch no longer applies following the Perl namespace changes, can you
> please submit a rebased version? Marking the patch "Waiting on Author".
As the thread has stalled, and the OP email bounces, I'm marking this patch
Returned with
This patch no longer applies following the Perl namespace changes, can you
please submit a rebased version? Marking the patch "Waiting on Author".
--
Daniel Gustafsson https://vmware.com/
On 22.07.21 10:39, Peifeng Qiu wrote:
I've slightly modified the patch to support "gssencmode" and added TAP
tests.
For the TAP tests, please put then under src/test/kerberos/, instead of
copying the whole infrastructure to contrib/postgres_fdw/. Just make a
new file, for example
e
Subject: Kerberos delegation support in libpq and postgres_fdw
Hi hackers.
This is the patch to add kerberos delegation support in libpq, which
enables postgres_fdw to connect to another server and authenticate
as the same user to the current login user. This will obsolete my
previous p
Hi hackers.
This is the patch to add kerberos delegation support in libpq, which
enables postgres_fdw to connect to another server and authenticate
as the same user to the current login user. This will obsolete my
previous patch which requires keytab file to be present on the fdw
server host.
35 matches
Mail list logo
