On Mon, Jan 23, 2023 at 3:50 PM Jeff Davis wrote:
> I believe your patch conflates two use cases:
>
> (A) Tightly-coupled servers that are managed by the administrator. In
> this case, there are a finite number of connection strings to make, and
> the admin knows about all of them. Validation is
On Tue, Jan 24, 2023 at 5:50 AM Robert Haas wrote:
> I think this has some potential, but it's pretty complex, seeming to
> require protocol extensions and having backward-compatibility problems
> and so on.
Yeah.
> What do you think about something in the spirit of a
> reverse-pg_hba.conf? The
On 2023-01-24 Tu 08:50, Robert Haas wrote:
>
> What do you think about something in the spirit of a
> reverse-pg_hba.conf? The idea being that PostgreSQL facilities that
> make outbound connections are supposed to ask it whether those
> connections are OK to initiate. Then you could have a
On Mon, Jan 23, 2023 at 7:24 PM Jacob Champion wrote:
> > The password requirement just *barely* prevents that attack from
> > working, almost, maybe, while at the same time managing to block
> > things that people want to do for totally legitimate reasons. But
> > IMHO, the real problem is that
On 1/23/23 11:52, Robert Haas wrote:
> On Mon, Jan 23, 2023 at 2:47 PM Robert Haas wrote:
>> Second, the reason why I described it as a manufactured issue is
>> because it's a bit like asking someone to stand under a ladder and
>> then complaining when they get hit in the head by a falling
On 1/23/23 11:05, Andres Freund wrote:
> There's not enough documentation for SYSTEM_USER imo.
If we were to make use of SYSTEM_USER programmatically (and based on
what Robert wrote downthread, that's probably not what's desired), I
think we'd have to make more guarantees about how it can be
On Fri, 2023-01-20 at 11:08 -0500, Robert Haas wrote:
> On Fri, Jan 20, 2023 at 8:25 AM Robert Haas
> wrote:
> > I still think you're talking about a different problem here. I'm
> > talking about the problem of knowing whether local files are going
> > to
> > be accessed by the connection string.
On Mon, Jan 23, 2023 at 2:47 PM Robert Haas wrote:
> Second, the reason why I described it as a manufactured issue is
> because it's a bit like asking someone to stand under a ladder and
> then complaining when they get hit in the head by a falling object.
> It's not that I think it's good for
On Mon, Jan 23, 2023 at 1:27 PM Jacob Champion wrote:
> On Mon, Jan 23, 2023 at 8:35 AM Robert Haas wrote:
> > I will admit that this is not an open-and-shut case, because a
> > passwordless login back to the bootstrap superuser account from the
> > local machine is a pretty common scenario and
Hi,
On 2023-01-23 10:27:27 -0800, Jacob Champion wrote:
> On Mon, Jan 23, 2023 at 8:35 AM Robert Haas wrote:
> > I will admit that this is not an open-and-shut case, because a
> > passwordless login back to the bootstrap superuser account from the
> > local machine is a pretty common scenario
On Mon, Jan 23, 2023 at 1:26 PM Andres Freund wrote:
> > If I'm asked to attempt to connect to a PostgreSQL server, and I
> > choose to do that, and the connection succeeds, all I know is that the
> > connection actually succeeded.
>
> Well, there is PQconnectionUsedPassword()... Not that it's a
Hi,
On 2023-01-23 12:39:50 -0500, Robert Haas wrote:
> On Sun, Jan 22, 2023 at 8:52 PM Andres Freund wrote:
> > > Perhaps we should have a way to directly turn on/off authentication
> > > methods in libpq through API functions and/or options?
> >
> > Yes. There's an in-progress patch adding, I
On Mon, Jan 23, 2023 at 8:35 AM Robert Haas wrote:
> I will admit that this is not an open-and-shut case, because a
> passwordless login back to the bootstrap superuser account from the
> local machine is a pretty common scenario and doesn't feel
> intrinsically unreasonable to me, and I hadn't
Hi,
On 2023-01-23 11:34:32 -0500, Robert Haas wrote:
> I will admit that this is not an open-and-shut case, because a
> passwordless login back to the bootstrap superuser account from the
> local machine is a pretty common scenario and doesn't feel
> intrinsically unreasonable to me, and I hadn't
On Sat, Jan 21, 2023 at 5:11 PM Andres Freund wrote:
> > + /* For all these parameters, the value is a local filename. */
> > + if (strcmp(opt->keyword, "passfile") == 0 ||
> > + strcmp(opt->keyword, "sslcert") == 0 ||
> > +
On Sun, Jan 22, 2023 at 8:52 PM Andres Freund wrote:
> > Perhaps we should have a way to directly turn on/off authentication
> > methods in libpq through API functions and/or options?
>
> Yes. There's an in-progress patch adding, I think, pretty much what is
> required here:
>
On Sat, Jan 21, 2023 at 5:01 PM Andres Freund wrote:
> There are good reasons to have 'peer' authentication set up for the user
> running postgres, so admin scripts can connect without issues. Which
> unfortunately then also means that postgres_fdw etc can connect to the current
> database as
Hi,
On 2023-01-22 09:05:27 -0800, Jeff Davis wrote:
> On Sat, 2023-01-21 at 14:01 -0800, Andres Freund wrote:
> > There are good reasons to have 'peer' authentication set up for the
> > user
> > running postgres, so admin scripts can connect without issues. Which
> > unfortunately then also means
On Sat, 2023-01-21 at 14:01 -0800, Andres Freund wrote:
> There are good reasons to have 'peer' authentication set up for the
> user
> running postgres, so admin scripts can connect without issues. Which
> unfortunately then also means that postgres_fdw etc can connect to
> the current
> database
Hi,
On 2023-01-20 11:08:54 -0500, Robert Haas wrote:
> /*
> - * Validate connection info string (just try to parse it)
> + * Validate connection info string, and determine whether it might cause
> + * local filesystem access to be attempted.
> + *
> + * If the connection string can't be parsed,
Hi,
On 2023-01-20 08:25:46 -0500, Robert Haas wrote:
> Worse still, I have always felt that the security vulnerability that
> led to these controls being installed is pretty much fabricated: it's
> an imaginary problem. Today I went back and found the original CVE at
>
On Fri, Jan 20, 2023 at 8:25 AM Robert Haas wrote:
> I still think you're talking about a different problem here. I'm
> talking about the problem of knowing whether local files are going to
> be accessed by the connection string.
So here's a dumb patch for this. At least in my mind, the
On Thu, Jan 19, 2023 at 8:46 PM Andres Freund wrote:
> > I wouldn't be OK with writing our own connection string parser for
> > this purpose, but using PQconninfoParse seems OK. We still have to
> > embed knowledge of which connection string parameters can trigger
> > local file access, but that
On Thu, 2023-01-19 at 17:51 -0800, Andres Freund wrote:
> I don't think we need to support complicated restriction schemes
> around this
> now. I'm sure such needs exist, but I think there's more places where
> a simple
> "allowed/not allowed" suffices.
If we did follow a path like 3 (having some
Hi,
On 2023-01-19 17:16:20 -0800, Jeff Davis wrote:
> The predefined role is probably the biggest user-facing part of the
> change. Does it mean that members can create any number of any kind of
> subscription?
I don't think we need to support complicated restriction schemes around this
now. I'm
Hi,
On 2023-01-19 10:45:35 -0500, Robert Haas wrote:
> On Wed, Jan 18, 2023 at 3:58 PM Mark Dilger
> wrote:
> > > On Jan 18, 2023, at 12:51 PM, Robert Haas wrote:
> > >
> > > Unless I'm missing something, it seems like this could be a quite small
> > > patch.
> >
> > I didn't like the idea of
On Thu, 2023-01-19 at 14:11 -0500, Robert Haas wrote:
> I guess I'm not quite seeing it. Why can't we write a small patch to
> get this working right now, probably in a few hours, and deal with
> any
> improvements that people want at a later time?
To me, it's worrisome when there are more than a
rhaps the answer is that it will be a small patch to get non-
> superuser subscription owners, but we need three or four preliminary
> patches first.
I guess I'm not quite seeing it. Why can't we write a small patch to
get this working right now, probably in a few hours, and deal with any
improve
o
support a way to pass SSL keys as values rather than file paths, so
that we can still do SSL.
So perhaps the answer is that it will be a small patch to get non-
superuser subscription owners, but we need three or four preliminary
patches first.
--
Jeff Davis
PostgreSQL Contributor Team - AWS
On Wed, 2023-01-18 at 14:38 -0500, Robert Haas wrote:
> I was just noticing that what was committed here didn't actually fix
> the problem implied by the subject line. That is, non-superuser still
> can't own subscriptions. To put that another way, there's no way for
> the superuser to delegate
On Wed, Jan 18, 2023 at 3:58 PM Mark Dilger
wrote:
> > On Jan 18, 2023, at 12:51 PM, Robert Haas wrote:
> >
> > Unless I'm missing something, it seems like this could be a quite small
> > patch.
>
> I didn't like the idea of the create/alter subscription commands needing to
> parse the
> On Jan 18, 2023, at 12:51 PM, Robert Haas wrote:
>
> Unless I'm missing something, it seems like this could be a quite small patch.
I didn't like the idea of the create/alter subscription commands needing to
parse the connection string and think about what it might do, because at some
just appear simpler but in truth turn into a
> can of worms. I don't know, since I never went as far as trying to implement
> either approach.
>
> Idea (2) seems to contemplate non-superuser subscription owners as a
> theoretical thing, but it's quite real already. Again,
are different ways of solving (1), and Jeff and I discussed them in Dec
2021. My recollection was that idea (3) was the cleanest. Other ideas might
be simpler than (3), or they may just appear simpler but in truth turn into a
can of worms. I don't know, since I never went as far as trying to implemen
On Sat, Jan 8, 2022 at 2:38 AM Jeff Davis wrote:
> Committed.
I was just noticing that what was committed here didn't actually fix
the problem implied by the subject line. That is, non-superuser still
can't own subscriptions. To put that another way, there's no way for
the superuser to delegate
Jeff Davis writes:
> On Sat, 2022-01-08 at 12:57 -0500, Tom Lane wrote:
>> ... btw, I'd like to complain that this new test script consumes
>> a completely excessive amount of time.
> Should be fixed now; I brought the number of tests down from 100 to 14.
> It's not running in 2 seconds on my
On Sat, 2022-01-08 at 12:57 -0500, Tom Lane wrote:
> ... btw, I'd like to complain that this new test script consumes
> a completely excessive amount of time.
Should be fixed now; I brought the number of tests down from 100 to 14.
It's not running in 2 seconds on my machine, but it's in line with
... btw, I'd like to complain that this new test script consumes
a completely excessive amount of time. On my fairly-new primary
workstation:
[12:48:00] t/027_nosuperuser.pl ... ok22146 ms ( 0.02 usr 0.00
sys + 1.12 cusr 0.95 csys = 2.09 CPU)
The previously-slowest script
Jeff Davis writes:
> I'm not sure I follow the reasoning. Are you saying that, to logically
> replay a simple DELETE, the subscription owner should have SELECT
> privileges on the destination table?
We consider that DELETE WHERE requires SELECT privilege
on the column(s) read by the . I
On Sat, 2022-01-08 at 15:35 +0530, Amit Kapila wrote:
> On Sat, Jan 8, 2022 at 1:01 PM Jeff Davis wrote:
> >
> > On Sat, 2022-01-08 at 12:27 +0530, Amit Kapila wrote:
> > > For Update/Delete, we do read the table first via
> > > FindReplTupleInLocalRel(), so is there a need to check ACL_SELECT
>
On Sat, Jan 8, 2022 at 1:01 PM Jeff Davis wrote:
>
> On Sat, 2022-01-08 at 12:27 +0530, Amit Kapila wrote:
> > For Update/Delete, we do read the table first via
> > FindReplTupleInLocalRel(), so is there a need to check ACL_SELECT
> > before that?
>
> If it's logically an update/delete, then I
On Wed, 2021-12-15 at 12:23 -0800, Mark Dilger wrote:
> > On Nov 24, 2021, at 4:30 PM, Jeff Davis wrote:
> >
> > We need to do permission checking for WITH CHECK OPTION and RLS.
> > The
> > patch right now allows the subscription to write data that an RLS
> > policy forbids.
>
> Version 4 of
On Sat, 2022-01-08 at 12:27 +0530, Amit Kapila wrote:
> For Update/Delete, we do read the table first via
> FindReplTupleInLocalRel(), so is there a need to check ACL_SELECT
> before that?
If it's logically an update/delete, then I think ACL_UPDATE/DELETE is
the right one to check. Do you have a
On Thu, Dec 16, 2021 at 1:53 AM Mark Dilger
wrote:
>
> > On Nov 24, 2021, at 4:30 PM, Jeff Davis wrote:
> >
> > We need to do permission checking for WITH CHECK OPTION and RLS. The
> > patch right now allows the subscription to write data that an RLS
> > policy forbids.
>
> Version 4 of the
> On Nov 24, 2021, at 4:30 PM, Jeff Davis wrote:
>
> We need to do permission checking for WITH CHECK OPTION and RLS. The
> patch right now allows the subscription to write data that an RLS
> policy forbids.
Version 4 of the patch, attached, no longer allows RLS to be circumvented, but
does
On Fri, Dec 10, 2021 at 7:39 PM Robert Haas wrote:
>
> On Thu, Dec 9, 2021 at 11:15 PM Amit Kapila wrote:
> > Yeah, to me also (b) sounds better than (a). However, a few points
> > that we might want to consider in that regard are as follows: 1.
> > locking the subscription for each transaction
On 12/10/21 09:09, Robert Haas wrote:
> On Thu, Dec 9, 2021 at 11:15 PM Amit Kapila wrote:
>> Yeah, to me also (b) sounds better than (a). However, a few points
>> that we might want to consider in that regard are as follows: 1.
>> locking the subscription for each transaction will add new
On Thu, Dec 9, 2021 at 11:15 PM Amit Kapila wrote:
> Yeah, to me also (b) sounds better than (a). However, a few points
> that we might want to consider in that regard are as follows: 1.
> locking the subscription for each transaction will add new blocking
> areas considering we acquire
On Thu, Dec 9, 2021 at 10:52 PM Mark Dilger
wrote:
>
> > On Dec 9, 2021, at 7:41 AM, Robert Haas wrote:
> >
> > On Tue, Nov 30, 2021 at 6:55 AM Amit Kapila wrote:
> >>> This patch does detect ownership changes more quickly (at the
> >>> transaction boundary) than the current code (only when it
> On Dec 9, 2021, at 7:47 AM, Robert Haas wrote:
>
> 1 and 2B seem to require changing the same code, or related code. 1A
> seems to require a completely different set of changes. If I'm right
> about that, it seems like a good reason for doing 1+2B first and
> leaving 2A for a separate
> On Dec 9, 2021, at 7:41 AM, Robert Haas wrote:
>
> On Tue, Nov 30, 2021 at 6:55 AM Amit Kapila wrote:
>>> This patch does detect ownership changes more quickly (at the
>>> transaction boundary) than the current code (only when it reloads for
>>> some other reason). Transaction boundary
On Wed, Dec 8, 2021 at 11:58 PM Amit Kapila wrote:
> But, I think as soon as we are trying to fix (b), we seem to be
> allowing non-superusers to apply changes. If we want to do that then
> we should be even allowed to change the owners to non-superusers. I
> was thinking of the below order:
> 1.
On Tue, Nov 30, 2021 at 6:55 AM Amit Kapila wrote:
> > This patch does detect ownership changes more quickly (at the
> > transaction boundary) than the current code (only when it reloads for
> > some other reason). Transaction boundary seems like a reasonable time
> > to detect the change to me.
On Tue, Dec 7, 2021 at 8:25 PM Mark Dilger wrote:
>
> > On Dec 7, 2021, at 2:29 AM, Amit Kapila wrote:
> >
> > Okay, let me try to explain again. Following is the text from docs
> > [1]: " (a) To create a subscription, the user must be a superuser. (b)
> > The subscription apply process will run
> On Dec 7, 2021, at 2:29 AM, Amit Kapila wrote:
>
> Okay, let me try to explain again. Following is the text from docs
> [1]: " (a) To create a subscription, the user must be a superuser. (b)
> The subscription apply process will run in the local database with the
> privileges of a
On Mon, Dec 6, 2021 at 9:26 PM Mark Dilger wrote:
>
> > On Dec 6, 2021, at 2:19 AM, Amit Kapila wrote:
> >
> >>> If we want to maintain the property that subscriptions can only be
> >>> owned by superuser
>
> We don't want to maintain such a property, or at least, that's not what I
> want. I
Le lundi 6 décembre 2021, 16:56:56 CET Mark Dilger a écrit :
> > On Dec 6, 2021, at 2:19 AM, Amit Kapila wrote:
> >>> If we want to maintain the property that subscriptions can only be
> >>> owned by superuser
>
> We don't want to maintain such a property, or at least, that's not what I
> want.
> On Dec 6, 2021, at 2:19 AM, Amit Kapila wrote:
>
>>> If we want to maintain the property that subscriptions can only be
>>> owned by superuser
We don't want to maintain such a property, or at least, that's not what I want.
I don't think that's what Jeff wants, either.
To clarify, I'm
On Fri, Dec 3, 2021 at 10:37 PM Mark Dilger
wrote:
>
> > On Dec 2, 2021, at 1:29 AM, Amit Kapila wrote:
> >
> > If we want to maintain the property that subscriptions can only be
> > owned by superuser for your first version then isn't a simple check
> > like ((!superuser()) for each of the
> On Dec 2, 2021, at 1:29 AM, Amit Kapila wrote:
>
> If we want to maintain the property that subscriptions can only be
> owned by superuser for your first version then isn't a simple check
> like ((!superuser()) for each of the operations is sufficient?
As things stand today, nothing
On Thu, Dec 2, 2021 at 12:51 AM Mark Dilger
wrote:
>
>
> > On Dec 1, 2021, at 5:36 AM, Amit Kapila wrote:
> >
> > On Wed, Dec 1, 2021 at 2:12 AM Jeff Davis wrote:
> >>
> >> On Tue, 2021-11-30 at 17:25 +0530, Amit Kapila wrote:
> >>> I think it would be better to do it before we allow
> On Dec 1, 2021, at 5:36 AM, Amit Kapila wrote:
>
> On Wed, Dec 1, 2021 at 2:12 AM Jeff Davis wrote:
>>
>> On Tue, 2021-11-30 at 17:25 +0530, Amit Kapila wrote:
>>> I think it would be better to do it before we allow subscription
>>> owners to be non-superusers.
>>
>> There are a couple
On Wed, Dec 1, 2021 at 2:12 AM Jeff Davis wrote:
>
> On Tue, 2021-11-30 at 17:25 +0530, Amit Kapila wrote:
> > I think it would be better to do it before we allow subscription
> > owners to be non-superusers.
>
> There are a couple other things to consider before allowing non-
> superusers to
On Tue, 2021-11-30 at 17:25 +0530, Amit Kapila wrote:
> I think it would be better to do it before we allow subscription
> owners to be non-superusers.
There are a couple other things to consider before allowing non-
superusers to create subscriptions anyway. For instance, a non-
superuser
On Tue, Nov 30, 2021 at 12:56 AM Jeff Davis wrote:
>
> On Mon, 2021-11-29 at 09:43 +0530, Amit Kapila wrote:
> > The first reason is that way it would be consistent with what we can
> > see while doing the operations from the backend.
>
> Logical replication is not interactive, so it doesn't seem
On Mon, Nov 29, 2021 at 11:52 PM Jeff Davis wrote:
>
> On Mon, 2021-11-29 at 08:26 -0800, Mark Dilger wrote:
>
> > > I agree that if we want to do all of this then that would require a
> > > lot of changes. However, giving an error for RLS-enabled tables
> > > might
> > > also be too restrictive.
On Mon, 2021-11-29 at 09:43 +0530, Amit Kapila wrote:
> The first reason is that way it would be consistent with what we can
> see while doing the operations from the backend.
Logical replication is not interactive, so it doesn't seem quite the
same.
If you have a long running INSERT INTO SELECT
On Mon, 2021-11-29 at 08:26 -0800, Mark Dilger wrote:
> > On Nov 28, 2021, at 9:56 PM, Amit Kapila
> > wrote:
> >
> > In ExecUpdate(), we convert Update to DELETE+INSERT when the
> > partition constraint is failed whereas, on the subscriber-side, it
> > will simply fail in this case.
Thank you,
ated to this patch but surely it will be a good
> improvement on its own and might help if that requires us to change
> some infrastructure here like hooking into executor at a higher level.
I would rather get a fix for non-superuser subscription owners committed than
expand the scope of work and have
On Sat, Nov 27, 2021 at 11:37 PM Mark Dilger
wrote:
>
>
>
> > On Nov 24, 2021, at 4:30 PM, Jeff Davis wrote:
> >
> > We need to do permission checking for WITH CHECK OPTION and RLS. The
> > patch right now allows the subscription to write data that an RLS
> > policy forbids.
>
> Thanks for
On Fri, Nov 26, 2021 at 1:36 AM Jeff Davis wrote:
>
> > as soon as possible instead of at the transaction
> > boundary.
>
> I don't understand why it's important to detect a loss of privileges
> faster than a transaction boundary. Can you elaborate?
>
The first reason is that way it would be
> On Nov 24, 2021, at 4:30 PM, Jeff Davis wrote:
>
> We need to do permission checking for WITH CHECK OPTION and RLS. The
> patch right now allows the subscription to write data that an RLS
> policy forbids.
Thanks for reviewing and for this observation! I can verify that RLS is not
being
On Thu, 2021-11-25 at 09:51 +0530, Amit Kapila wrote:
> Won't it be better to just check if the current user is superuser
> before applying each change as a matter of this first patch? Sorry, I
> was under impression that first, we want to close the current gap
> where we allow to proceed with
On Thu, Nov 25, 2021 at 6:00 AM Jeff Davis wrote:
>
> On Fri, 2021-11-19 at 16:45 -0800, Mark Dilger wrote:
> > Renamed as 0001 in version 3, as it is the only remaining patch. For
> > anyone who reviewed the older patch set, please note that I made some
> > changes to the
On Fri, 2021-11-19 at 16:45 -0800, Mark Dilger wrote:
> Renamed as 0001 in version 3, as it is the only remaining patch. For
> anyone who reviewed the older patch set, please note that I made some
> changes to the src/test/subscription/t/026_nosuperuser.pl test case
> relative to the prior
> On Nov 19, 2021, at 7:25 AM, Mark Dilger wrote:
>
> Jeff Davis and I had a long conversation off-list yesterday and reached the
> same conclusion. I will be submitting a version of 0003 which does not
> depend on the prior two patches.
Renamed as 0001 in version 3, as it is the only
> On Nov 19, 2021, at 2:23 AM, Amit Kapila wrote:
>
> I was thinking why not separate the ownership and "run as" privileges
> for the subscriptions? We can introduce a new syntax in addition to
> the current syntax for "Owner" for this as:
>
> Create Subscription sub RUNAS ...;
> Alter
> On Nov 19, 2021, at 1:56 AM, Amit Kapila wrote:
>
> How about allowing to change ownership only for disabled
> subscriptions? Basically, users need to first disable the subscription
> and then change its ownership.
There are some open issues about non-superuser owners that Jeff would like
> On Nov 19, 2021, at 1:44 AM, Amit Kapila wrote:
>
> I think we are saying the same thing. I intend to say that your 0003*
> patch closes the current gap in the code and we should consider
> applying it irrespective of what we do with respect to changing the
> ... OWNER TO .. behavior. Is
On Fri, Nov 19, 2021 at 12:00 AM Jeff Davis wrote:
>
> On Wed, 2021-11-17 at 16:17 -0800, Mark Dilger wrote:
> > You must choose a single role you want the subscription to run
> > under.
>
> I think that was the source of a lot of my confusion:
>
> Your patches are creating the notion of a "run
On Thu, Nov 18, 2021 at 9:15 PM Mark Dilger
wrote:
>
> The prior version of the patch only picked up the change if it happened to
> start a new worker, but could process multiple transactions without noticing
> the change. Now, it is limited to finishing the current transaction. Would
> you
pose of this patch. The only sense in which this
> >> patch depends on that issue is that this patch proposes that non-superuser
> >> subscription owners are already an issue, and therefore that this patch
> >> isn't creating a new issue, but rather making more sane so
On Wed, 2021-11-17 at 16:17 -0800, Mark Dilger wrote:
> Some of what I perceive as the screwiness of your argument I must
> admin is not your fault. The properties of subscriptions are defined
> in ways that don't make sense to me. It would be far more sensible
> if connection strings were
On Wed, 2021-11-17 at 16:17 -0800, Mark Dilger wrote:
> You must choose a single role you want the subscription to run
> under.
I think that was the source of a lot of my confusion:
Your patches are creating the notion of a "run as" user by assigning
ownership-that-isn't-really-ownership. I
> On Nov 18, 2021, at 3:37 AM, Amit Kapila wrote:
>
>> I have rethought my prior analysis. The problem in the previous patch was
>> that the subscription apply workers did not check for a change in ownership
>> the way they checked for other changes, instead only picking up the new
>>
er than have it continue to
>> be owned by the recently-non-superuser. If you have a better idea, we can
>> discuss it, but to some degree I think that is also orthogonal to the
>> purpose of this patch. The only sense in which this patch depends on that
>> issue is that thi
On Thu, Nov 4, 2021 at 1:20 AM Mark Dilger wrote:
>
> > On Nov 1, 2021, at 10:58 AM, Mark Dilger
> > wrote:
> >
> > ALTER SUBSCRIPTION..[ENABLE | DISABLE] do not synchronously start or stop
> > subscription workers. The ALTER command updates the catalog's subenabled
> > field, but workers
pose
> of this patch. The only sense in which this patch depends on that issue is
> that this patch proposes that non-superuser subscription owners are already
> an issue, and therefore that this patch isn't creating a new issue, but
> rather making more sane something that already
gt; and didn't see what we should do with the subscription other than
>> have it continue to be owned by the recently-non-superuser. If you
>> have a better idea, we can discuss it, but to some degree I think
>> that is also orthogonal to the purpose of this patch. The only sense
>&
On Wed, 2021-11-17 at 15:07 -0800, Mark Dilger wrote:
> We only have 4 values left in the bitmask, and I doubt that burning
> those slots for multiple new types of rights that only have meaning
> for subscriptions is going to be accepted. For full disclosure, I'm
> proposing adding ACL_SET and
> On Nov 17, 2021, at 1:10 PM, Jeff Davis wrote:
>
> I think you misunderstood the idea: not using predefined roles, just
> plain old ordinary GRANT on a subscription object to ordinary roles.
>
> GRANT REFRESH ON SUBSCRIPTION sub1 TO nonsuper;
>
> This should be easy enough because the
On Wed, 2021-11-17 at 10:48 -0800, Mark Dilger wrote:
> GRANT *might* be part of some solution, but it is unclear to me how
> best to do it. The various configuration parameters on subscriptions
> entail different security concerns. We might take a fine-grained
> approach and create a predefined
etter idea, we can discuss it, but to some degree I think
> that is also orthogonal to the purpose of this patch. The only sense
> in which this patch depends on that issue is that this patch proposes
> that non-superuser subscription owners are already an issue, and
> therefore that this pa
On 11/16/21 15:06, Andrew Dunstan wrote:
> On 11/3/21 15:50, Mark Dilger wrote:
>>> On Nov 1, 2021, at 10:58 AM, Mark Dilger
>>> wrote:
>>>
>>> ALTER SUBSCRIPTION..[ENABLE | DISABLE] do not synchronously start or stop
>>> subscription workers. The ALTER command updates the catalog's
> On Nov 17, 2021, at 9:33 AM, Jeff Davis wrote:
>
> Is GRANT a better fit here? That would allow more than one user to
> REFRESH, or ENABLE/DISABLE the same subscription. It wouldn't allow
> RENAME, but I don't see why we'd separate privileges for
> CREATE/DROP/RENAME anyway.
I don't think
we should do with the subscription other than have it continue to be
owned by the recently-non-superuser. If you have a better idea, we can discuss
it, but to some degree I think that is also orthogonal to the purpose of this
patch. The only sense in which this patch depends on that issue is th
On Wed, 2021-11-17 at 07:44 -0800, Mark Dilger wrote:
> Administrators may quite
> intentionally create low-power users, ones without access to anything
> but a single table, or a single schema, as a means of restricting the
> damage that a subscription might do (or more precisely, what the
>
> On Nov 16, 2021, at 8:11 PM, Jeff Davis wrote:
>
> On Wed, 2021-11-03 at 12:50 -0700, Mark Dilger wrote:
>> The first two patches are virtually unchanged. The third updates the
>> behavior of the apply workers, and updates the documentation to
>> match.
>
> v2-0001 corrects some
On Wed, 2021-11-03 at 12:50 -0700, Mark Dilger wrote:
> The first two patches are virtually unchanged. The third updates the
> behavior of the apply workers, and updates the documentation to
> match.
v2-0001 corrects some surprises, but may create others. Why is renaming
allowed, but not
On 11/16/21 15:08, Mark Dilger wrote:
>
>> On Nov 16, 2021, at 12:06 PM, Andrew Dunstan wrote:
>>
>> There doesn't seem to be a CF item for it but I'm
>> inclined to commit it in a couple of days time.
> https://commitfest.postgresql.org/36/3414/
>
OK, got it, thanks.
cheers
andrew
--
101 - 200 of 211 matches
Mail list logo
