On Thu, Mar 21, 2019 at 9:28 PM Michael Paquier wrote:
> By the way, as the commit fest is coming to its end in a couple of
> days, and that we are still discussing how the thing should be shaped,
> I would recommend to mark the patch as returned with feedback. Any
> objections with that?
+1. I
On Sat, Mar 23, 2019 at 10:52:52AM -0400, Stephen Frost wrote:
> * Petr Jelinek (petr.jeli...@2ndquadrant.com) wrote:
>> I agree the feature is important, it just does not seem like the patch
>> is RFC and given security implications I err on the side of safety here.
>
> Agreed.
Based on the late
Greetings,
* Petr Jelinek (petr.jeli...@2ndquadrant.com) wrote:
> On 23/03/2019 02:38, Michael Paquier wrote:
> > On Fri, Mar 22, 2019 at 08:41:06PM +0800, Andrey Borodin wrote:
> >> 22 марта 2019 г., в 19:17, Petr Jelinek
> >> написал(а):
> >>> I still don't like that we are running the subscri
On 23/03/2019 02:38, Michael Paquier wrote:
> On Fri, Mar 22, 2019 at 08:41:06PM +0800, Andrey Borodin wrote:
>> 22 марта 2019 г., в 19:17, Petr Jelinek
>> написал(а):
>>> I still don't like that we are running the subscription workers as
>>> superuser even for subscriptions created by regular us
On Fri, Mar 22, 2019 at 08:41:06PM +0800, Andrey Borodin wrote:
> 22 марта 2019 г., в 19:17, Petr Jelinek
> написал(а):
>> I still don't like that we are running the subscription workers as
>> superuser even for subscriptions created by regular user. That has
>> plenty of privilege escalation iss
Hi!
> 22 марта 2019 г., в 19:17, Petr Jelinek
> написал(а):
>
> I still don't like that we are running the subscription workers as
> superuser even for subscriptions created by regular user. That has
> plenty of privilege escalation issues in terms of how user functions are
> run (we execute t
Hi,
On 22/03/2019 03:15, Andrey Borodin wrote:
>
>> 22 марта 2019 г., в 9:28, Michael Paquier написал(а):
>>
>> On Thu, Mar 21, 2019 at 10:06:03AM -0300, Euler Taveira wrote:
>>> It will be really strange but I can live with that. Another idea is
>>> CREATE bit to create subscriptions (without r
Hi!
> These are basically that the truncate, insert, delete and insert
> rights for the role creating the subscription. Why would we actually
> need that?
It's for security reasons. Because possible to attack target server. If
publication have system tables for instance pg_authid
> pg_subscriptio
On Fri, Mar 22, 2019 at 10:15:59AM +0800, Andrey Borodin wrote:
> It seems to me that we have consensus that:
> 1. We need special role to create subscription
> 2. This role can create subscription with some security checks
> 3. We have complete list of possible security checks
These are basically
> 22 марта 2019 г., в 9:28, Michael Paquier написал(а):
>
> On Thu, Mar 21, 2019 at 10:06:03AM -0300, Euler Taveira wrote:
>> It will be really strange but I can live with that. Another idea is
>> CREATE bit to create subscriptions (without replicate) and SUBSCRIBE
>> bit to replicate tables.
On Thu, Mar 21, 2019 at 10:06:03AM -0300, Euler Taveira wrote:
> It will be really strange but I can live with that. Another idea is
> CREATE bit to create subscriptions (without replicate) and SUBSCRIBE
> bit to replicate tables. It is not just a privilege to create a
> subscription but also to mo
Em qua, 20 de mar de 2019 às 21:57, Michael Paquier
escreveu:
>
> Perhaps we would want something at database level different from GRANT
> CREATE ON DATABASE, but only for subscriptions? This way, it is
> possible to have per-database groups having the right to create
> subscriptions, and I'd lik
Hi!
> Perhaps we would want something at database level different from GRANT
> CREATE ON DATABASE, but only for subscriptions?
How about 4 checks to create subscription for nonsuperuser?
1. Special role for create subscription
2. CREATE ON DATABASE privilege
3. INSERT, UPDATE, DELETE, TRUNCATE,
Hi!
> - If the user's permissions are later revoked, the subscription is unaffected.
Now it work the same, if we revoke superuser, subscription is unaffected and
replication still work
Don't check grants in target database is very dangerous, i create publication
with system tables(it's not diffi
> 21 марта 2019 г., в 8:56, Michael Paquier написал(а):
>
> On Wed, Mar 20, 2019 at 11:58:04PM +0800, Andrey Borodin wrote:
>>> 20 марта 2019 г., в 21:46, Robert Haas написал(а):
>>> I think we should view this permission as "you can create
>>> subscriptions, plain and simple".
>>
>> That so
On Wed, Mar 20, 2019 at 11:58:04PM +0800, Andrey Borodin wrote:
>> 20 марта 2019 г., в 21:46, Robert Haas написал(а):
>> I think we should view this permission as "you can create
>> subscriptions, plain and simple".
>
> That sounds good.
> From my POV, the purpose of the patch is to allow users t
> 20 марта 2019 г., в 21:46, Robert Haas написал(а):
>
> On Wed, Mar 20, 2019 at 5:39 AM Evgeniy Efimkin
> wrote:
>> Hi!
>>> Currently, user with pg_subscription_users can create subscription into any
>>> system table, can't they?
>>> We certainly need to change it to more secure way.
>> No
On Wed, Mar 20, 2019 at 5:39 AM Evgeniy Efimkin wrote:
> Hi!
> > Currently, user with pg_subscription_users can create subscription into any
> > system table, can't they?
> > We certainly need to change it to more secure way.
> No, you can't add system tables to publication. In new patch i add pr
Hi!
> Currently, user with pg_subscription_users can create subscription into any
> system table, can't they?
> We certainly need to change it to more secure way.
No, you can't add system tables to publication. In new patch i add privileges
checks on target table, non superuser can't create/ref
Em qui, 14 de mar de 2019 às 00:03, Stephen Frost escreveu:
>
> I view that as the first step towards building a more granular privilege
> system for subscription creation, and that was the second half of what I
> was trying to say before- I do think there's value in having something
> more granul
Hi!
> 13 марта 2019 г., в 22:55, Evgeniy Efimkin
> написал(а):
>
> I've prepare patch with new system role, i'm not sure about name, called it
> "pg_subscription_users".
> In that patch we don't check permissions on target tables, i don't know,
> should we check it?
Currently, user with pg_s
> 14 марта 2019 г., в 12:56, Evgeniy Efimkin
> написал(а):
>
> Hi!
>> I view that as the first step towards building a more granular privilege
>> system for subscription creation, and that was the second half of what I
>> was trying to say before- I do think there's value in having something
Hi!
> I view that as the first step towards building a more granular privilege
> system for subscription creation, and that was the second half of what I
> was trying to say before- I do think there's value in having something
> more granular than just "this role can create ANY subscription". As an
At Wed, 13 Mar 2019 23:03:26 -0400, Stephen Frost wrote in
<20190314030326.gq6...@tamriel.snowman.net>
> Greetings,
>
> * Robert Haas (robertmh...@gmail.com) wrote:
> > On Mon, Mar 11, 2019 at 10:39 PM Michael Paquier
> > wrote:
> > > On Mon, Mar 11, 2019 at 06:32:10PM -0700, Jeff Davis wrote:
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Mon, Mar 11, 2019 at 10:39 PM Michael Paquier wrote:
> > On Mon, Mar 11, 2019 at 06:32:10PM -0700, Jeff Davis wrote:
> > > * Is the original idea of a special role still viable?
> >
> > In my opinion, that part may be valuable. The la
Hi!
Thanks for comments!
> Just letting the superuser decide who gets to create subscriptions
> seems good enough from here.
I've prepare patch with new system role, i'm not sure about name, called it
"pg_subscription_users".
In that patch we don't check permissions on target tables, i don't know,
On Mon, Mar 11, 2019 at 10:39 PM Michael Paquier wrote:
> On Mon, Mar 11, 2019 at 06:32:10PM -0700, Jeff Davis wrote:
> > * Is the original idea of a special role still viable?
>
> In my opinion, that part may be valuable. The latest patches proposed
> change the way tables are filtered and list
Hi!
I think it's good idea to able create subscription for database owner, but
owner do not have permission on all tables in database.
At the begging Stephen Frost said about table filter at subscription side.
https://www.postgresql.org/message-id/20181106215244.GH18594%40tamriel.snowman.net
I c
Hi!
> * What are the most important use cases here? Are we just trying to
> avoid the unnecessary use of superuser, or is there a real use case for
> subscribing to a subset of a publication?
For instance in target database we do not have permission on some table used in
publication,
but we stil
On Mon, Mar 11, 2019 at 06:32:10PM -0700, Jeff Davis wrote:
> * Is the original idea of a special role still viable?
In my opinion, that part may be valuable. The latest patches proposed
change the way tables are filtered and listed on the subscription
side, lowering the permission to spawn a ne
On Fri, 2018-11-09 at 15:24 +0300, Evgeniy Efimkin wrote:
> Hi!
> In order to support create subscription from non-superuser, we need
> to make it possible to choose tables on the subscriber side:
I'd like to know more about the reasoning here. This thread started out
by suggesting a new special r
Hello!
I started work on patch (draft attached). Draft has changes related only to
`CREATE SUBSCRIPTION`.
I also introduce a new status (DEFFERED) for tables in `FOR TABLE` clause (but
not in publication).
New column in pg_subscription (suballtables) will be used in `REFRESH` clause
09.11.2018
Hi!
In order to support create subscription from non-superuser, we need to make it
possible to choose tables on the subscriber side:
1. add `FOR TABLE` clause in `CREATE SUBSCRIPTION`:
```
CREATE SUBSCRIPTION subscription_name
CONNECTION 'conninfo'
PUBLIC
Hi!
I think we can add FOR TABLES clause for create/refresh subscription, for
example: CREATE SUBSCRIPTION my_sub CONNECTION ... PUBLICATION my_pub [WITH
...] [ FOR TABLES t1, t2 | ALL TABLES ]. ALL TABLES is avalibale only for
superuser. FOR TABLES t1, t2 is available to owner of tables and sup
Greetings,
* Evgeniy Efimkin (efim...@yandex-team.ru) wrote:
> As a first step I suggest we allow CREATE SUBSCRIPTION for table owner only.
That's a nice idea but seems like we would want to have a way to filter
what tables a subscription follows then..? Just failing if the
publication publishes
Hi!
As a first step I suggest we allow CREATE SUBSCRIPTION for table owner only.
03.11.2018, 19:20, "Stephen Frost" :
> Greetings,
>
> * Evgeniy Efimkin (efim...@yandex-team.ru) wrote:
>> In postgresql 10 and 11 only superuser can create/alter subscriptions.
>> If there was a special role (like
Greetings,
* Evgeniy Efimkin (efim...@yandex-team.ru) wrote:
> In postgresql 10 and 11 only superuser can create/alter subscriptions.
> If there was a special role (like pg_monitor), it would be more easy to grant
> control on subscriptions.
> I can make a patch if there are no objections against
Hi hackers!
In postgresql 10 and 11 only superuser can create/alter subscriptions.
If there was a special role (like pg_monitor), it would be more easy to grant
control on subscriptions.
I can make a patch if there are no objections against it.
38 matches
Mail list logo
