Re: [HACKERS] Proposal: SET ROLE hook

On 03/16/2016 08:28 AM, David Steele wrote: > On 3/6/16 1:17 AM, Pavel Stehule wrote: > >> 2016-03-05 21:49 GMT+01:00 Joe Conway > >: >> >> I still don't see any point in trying to pass data back from the hooks >> as the extension can

Re: [HACKERS] Proposal: SET ROLE hook

On 3/6/16 1:17 AM, Pavel Stehule wrote: > 2016-03-05 21:49 GMT+01:00 Joe Conway >: > > I still don't see any point in trying to pass data back from the hooks > as the extension can maintain that state just fine, although it looks >

Re: [HACKERS] Proposal: SET ROLE hook

2016-03-05 21:49 GMT+01:00 Joe Conway : > On 03/01/2016 08:18 AM, Pavel Stehule wrote: > > 2016-03-01 16:52 GMT+01:00 Joe Conway: > > On 03/01/2016 02:09 AM, Pavel Stehule wrote: > > > > On 01/06/2016 10:36 AM, Tom Lane wrote: > > > >> I think a design that

Re: [HACKERS] Proposal: SET ROLE hook

Joe Conway writes: > I still don't see any point in trying to pass data back from the hooks > as the extension can maintain that state just fine, although it looks > like it would be pretty trivial to do using a new void* member added to > role_auth_extra. Tom (or anyone

Re: [HACKERS] Proposal: SET ROLE hook

On 6 March 2016 at 04:49, Joe Conway wrote: > I still don't see any point in trying to pass data back from the hooks > as the extension can maintain that state just fine, although it looks > like it would be pretty trivial to do using a new void* member added to >

Re: [HACKERS] Proposal: SET ROLE hook

On 03/01/2016 08:18 AM, Pavel Stehule wrote: > 2016-03-01 16:52 GMT+01:00 Joe Conway: > On 03/01/2016 02:09 AM, Pavel Stehule wrote: > > > On 01/06/2016 10:36 AM, Tom Lane wrote: > > >> I think a design that was actually somewhat robust would require > two > > >>

Re: [HACKERS] Proposal: SET ROLE hook

2016-03-01 16:52 GMT+01:00 Joe Conway : > On 03/01/2016 02:09 AM, Pavel Stehule wrote: > > 2016-02-29 2:40 GMT+01:00 Joe Conway > >: > > > > On 01/07/2016 09:08 AM, Joe Conway wrote: > > > On 01/06/2016 10:36 AM, Tom

Re: [HACKERS] Proposal: SET ROLE hook

On 03/01/2016 02:09 AM, Pavel Stehule wrote: > 2016-02-29 2:40 GMT+01:00 Joe Conway >: > > On 01/07/2016 09:08 AM, Joe Conway wrote: > > On 01/06/2016 10:36 AM, Tom Lane wrote: > >> I think a design that was actually somewhat robust

Re: [HACKERS] Proposal: SET ROLE hook

Hi 2016-02-29 2:40 GMT+01:00 Joe Conway : > On 01/07/2016 09:08 AM, Joe Conway wrote: > > On 01/06/2016 10:36 AM, Tom Lane wrote: > >> I think a design that was actually somewhat robust would require two > >> hooks, one at check_role and one at assign_role, wherein the first

Re: [HACKERS] Proposal: SET ROLE hook

On 01/07/2016 09:08 AM, Joe Conway wrote: > On 01/06/2016 10:36 AM, Tom Lane wrote: >> I think a design that was actually somewhat robust would require two >> hooks, one at check_role and one at assign_role, wherein the first one >> would do any potentially-failing work and package all required

Re: [HACKERS] Proposal: SET ROLE hook

Joe Conway wrote: > On 01/06/2016 10:36 AM, Tom Lane wrote: > > I think a design that was actually somewhat robust would require two > > hooks, one at check_role and one at assign_role, wherein the first one > > would do any potentially-failing work and package all required info into > > a blob

Re: [HACKERS] Proposal: SET ROLE hook

Hi I did a review of this patch. 1. the proposal is clean and there are not any objection against it. I checked a implementation, and it does exactly same what was proposed. 2. This hook has impact only on SET role to XXX statement, what isn't used in our critical path, so there are not any

Re: [HACKERS] Proposal: SET ROLE hook

Ultimately I would also like to see a general hook available which would >> fire for all changes to GUC settings, but I think this one is still very >> useful as it is highly targeted. >> >> Comments? >> > > I read discussion in this thread and I am thinking so creating hook is the > most simple

Re: [HACKERS] Proposal: SET ROLE hook

Joe Conway writes: > Compared to both of these alternatives, I still feel that the specific > SET ROLE hook is cleanest and best path forward. If there are no other > comments or concerns, I will commit this in a day or two. While I don't think there's any great harm in

Re: [HACKERS] Proposal: SET ROLE hook

On 01/06/2016 02:39 AM, Pavel Stehule wrote: > I did a review of this patch. > > 1. the proposal is clean and there are not any objection against it. I > checked a implementation, and it does exactly same what was proposed. > > 2. This hook has impact only on SET role to XXX statement, what

Re: [HACKERS] Proposal: SET ROLE hook

Hi 2015-10-16 18:20 GMT+02:00 Joe Conway : > In many environments there is a policy requiring users to login using > unprivileged accounts, and then escalate their privileges if and when > they require it. In PostgreSQL this could be done by granting the > superuser role to

Re: [HACKERS] Proposal: SET ROLE hook

On 10/16/15 12:51 PM, Andres Freund wrote: >Hmmm, do you mean essentially skip the "GRANT postgres to joe" and use a >SECURITY DEFINER C function that does the set role to postgres under the >covers with "GRANT EXECUTE on FUNCTION elevate_user() to joe"? Yes. >Being able to use something like

Re: [HACKERS] Proposal: SET ROLE hook

On 2015-10-16 10:30:20 -0700, Joe Conway wrote: > On 10/16/2015 09:28 AM, Andres Freund wrote: > > Alternatively you can just have a elevate_user() function that does the > > logging and escalating? That seems like the same amount of code and it'd > > work with released versions of postgres? > >

Re: [HACKERS] Proposal: SET ROLE hook

Joe Conway writes: > In many environments there is a policy requiring users to login using > unprivileged accounts, and then escalate their privileges if and when > they require it. In PostgreSQL this could be done by granting the > superuser role to an unprivileged user with

[HACKERS] Proposal: SET ROLE hook

In many environments there is a policy requiring users to login using unprivileged accounts, and then escalate their privileges if and when they require it. In PostgreSQL this could be done by granting the superuser role to an unprivileged user with noinherit, and then making the superuser role

Re: [HACKERS] Proposal: SET ROLE hook

On 2015-10-16 09:20:26 -0700, Joe Conway wrote: > One of the problems with this is we would ideally like to know whenever > joe escalates himself to postgres. Right now that is not really possible > without doing untenable things such as logging every statement. Alternatively you can just have a

Re: [HACKERS] Proposal: SET ROLE hook

On 10/16/2015 09:28 AM, Andres Freund wrote: > Alternatively you can just have a elevate_user() function that does the > logging and escalating? That seems like the same amount of code and it'd > work with released versions of postgres? > > Sure, that has some disadvantages over your approach,