logical replication access control patches

Peter,

* Peter Eisentraut (peter.eisentraut@2ndquadrant.com) wrote:

0002 Add PUBLICATION privilege

Add a new privilege kind to tables to determine whether they can be
added to a publication.

I'm not convinced that it really makes sense to have PUBLICATION of a
table be independent from the rights an owner of a table has. We don't
allow other ALTER commands on objects based on GRANT'able rights, in
general, so I'm not really sure that it makes sense to do so here.

The downside of adding these privileges is that we're burning through
the last few bits in the ACLMASK for a privilege that doesn't really
seem like it's something that would be GRANT'd in general usage.

I have similar reservations regarding the proposed SUBSCRIPTION
privilege.

I'm certainly all for removing the need for users to be the superuser
for such commands, just not sure that they should be GRANT'able
privileges instead of privileges which the owner of the relation or
database has.

Thanks!

Stephen

On 2/18/17 18:06, Stephen Frost wrote:

I'm not convinced that it really makes sense to have PUBLICATION of a
table be independent from the rights an owner of a table has. We don't
allow other ALTER commands on objects based on GRANT'able rights, in
general, so I'm not really sure that it makes sense to do so here.

The REFERENCES and TRIGGER privileges are very similar in principle.

The downside of adding these privileges is that we're burning through
the last few bits in the ACLMASK for a privilege that doesn't really
seem like it's something that would be GRANT'd in general usage.

I don't see any reason why we couldn't increase the size of AclMode if
it becomes necessary.

I'm certainly all for removing the need for users to be the superuser
for such commands, just not sure that they should be GRANT'able
privileges instead of privileges which the owner of the relation or
database has.

Then you couldn't set up a replication structure involving tables owned
by different users without resorting to blunt instruments like having
everything owned by the same user or using superusers.

--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Peter,

* Peter Eisentraut (peter.eisentraut@2ndquadrant.com) wrote:

On 2/18/17 18:06, Stephen Frost wrote:

I'm not convinced that it really makes sense to have PUBLICATION of a
table be independent from the rights an owner of a table has. We don't
allow other ALTER commands on objects based on GRANT'able rights, in
general, so I'm not really sure that it makes sense to do so here.

The REFERENCES and TRIGGER privileges are very similar in principle.

TRIGGER is a great example of an, ultimately, poorly chosen privilege to
GRANT away, with a good history of discussion about it:

/messages/by-id/21827.1166115978@sss.pgh.pa.us
/messages/by-id/7389.1405554356@sss.pgh.pa.us

Further, how would RLS be handled with publication? I've been assuming
that it's simply ignored, but that's clearly wrong if a non-owner can
publish a table that they just have SELECT,PUBLISH on, isn't it?

The downside of adding these privileges is that we're burning through
the last few bits in the ACLMASK for a privilege that doesn't really
seem like it's something that would be GRANT'd in general usage.

I don't see any reason why we couldn't increase the size of AclMode if
it becomes necessary.

I've fought exactly that argument before and there is a good deal of
entirely reasonable push-back on increasing our catalogs by so much.

I'm certainly all for removing the need for users to be the superuser
for such commands, just not sure that they should be GRANT'able
privileges instead of privileges which the owner of the relation or
database has.

Then you couldn't set up a replication structure involving tables owned
by different users without resorting to blunt instruments like having
everything owned by the same user or using superusers.

That's not correct- you would simply need a user who is considered an
owner for all of the objects which you want to replicate, that doesn't
have to be a *direct* owner or a superuser.

The tables can have individual roles, with some admin role who is a
member of those other roles, or another mechanism (as Simon has proposed
not too long ago...) to have a given role be considered equivilant to an
owner for all of the relations in a particular database.

Thanks!

Stephen

On 28/02/17 04:10, Stephen Frost wrote:

Peter,

* Peter Eisentraut (peter.eisentraut@2ndquadrant.com) wrote:

On 2/18/17 18:06, Stephen Frost wrote:

I'm not convinced that it really makes sense to have PUBLICATION of a
table be independent from the rights an owner of a table has. We don't
allow other ALTER commands on objects based on GRANT'able rights, in
general, so I'm not really sure that it makes sense to do so here.

The REFERENCES and TRIGGER privileges are very similar in principle.

TRIGGER is a great example of an, ultimately, poorly chosen privilege to
GRANT away, with a good history of discussion about it:

/messages/by-id/21827.1166115978@sss.pgh.pa.us
/messages/by-id/7389.1405554356@sss.pgh.pa.us

Further, how would RLS be handled with publication? I've been assuming
that it's simply ignored, but that's clearly wrong if a non-owner can
publish a table that they just have SELECT,PUBLISH on, isn't it?

I don't see why would PUBLISH care about RLS.

The downside of adding these privileges is that we're burning through
the last few bits in the ACLMASK for a privilege that doesn't really
seem like it's something that would be GRANT'd in general usage.

I don't see any reason why we couldn't increase the size of AclMode if
it becomes necessary.

I've fought exactly that argument before and there is a good deal of
entirely reasonable push-back on increasing our catalogs by so much.

Hmm to be honest I don't see what's the issue there.

I'm certainly all for removing the need for users to be the superuser
for such commands, just not sure that they should be GRANT'able
privileges instead of privileges which the owner of the relation or
database has.

Then you couldn't set up a replication structure involving tables owned
by different users without resorting to blunt instruments like having
everything owned by the same user or using superusers.

That's not correct- you would simply need a user who is considered an
owner for all of the objects which you want to replicate, that doesn't
have to be a *direct* owner or a superuser.

The tables can have individual roles, with some admin role who is a
member of those other roles, or another mechanism (as Simon has proposed
not too long ago...) to have a given role be considered equivilant to an
owner for all of the relations in a particular database.

I do agree with this though. And I also agree with the overall sentiment
that we don't need special PUBLICATION privilege on tables.

I do like the rest of the patch.

--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

* Petr Jelinek (petr.jelinek@2ndquadrant.com) wrote:

On 28/02/17 04:10, Stephen Frost wrote:

Peter,

* Peter Eisentraut (peter.eisentraut@2ndquadrant.com) wrote:

On 2/18/17 18:06, Stephen Frost wrote:

I'm not convinced that it really makes sense to have PUBLICATION of a
table be independent from the rights an owner of a table has. We don't
allow other ALTER commands on objects based on GRANT'able rights, in
general, so I'm not really sure that it makes sense to do so here.

The REFERENCES and TRIGGER privileges are very similar in principle.

TRIGGER is a great example of an, ultimately, poorly chosen privilege to
GRANT away, with a good history of discussion about it:

/messages/by-id/21827.1166115978@sss.pgh.pa.us
/messages/by-id/7389.1405554356@sss.pgh.pa.us

Further, how would RLS be handled with publication? I've been assuming
that it's simply ignored, but that's clearly wrong if a non-owner can
publish a table that they just have SELECT,PUBLISH on, isn't it?

I don't see why would PUBLISH care about RLS.

Perhaps I'm missing something here, in which case I would certainly
welcome some clarification, but in curreng PG I can GRANT you access to
a table and then limit what you can see with it using RLS and policies.

If I then GRANT you the PUBLISH right- shouldn't that also respect the
RLS setting and the policies set on the table? Otherwise, PUBLISH is
allowing you to gain access to the data in the table that you wouldn't
normally be able to see with a simple SELECT.

We don't really even need to get to the RLS level to consider this
situation- what about column-level privileges?

Will users really understand that the PUBLISH right actually allows
complete access to the entire relation, rather than just the ability for
a user to PUBLISH what they are currently about to SELECT? It certainly
doesn't seem intuitive to me, which is why I am concerned that it's
going to lead to confusion and bug/security reports down the road, or,
worse, poorly configured systems.

The downside of adding these privileges is that we're burning through
the last few bits in the ACLMASK for a privilege that doesn't really
seem like it's something that would be GRANT'd in general usage.

I don't see any reason why we couldn't increase the size of AclMode if
it becomes necessary.

I've fought exactly that argument before and there is a good deal of
entirely reasonable push-back on increasing our catalogs by so much.

Hmm to be honest I don't see what's the issue there.

It's a not-insignificant increase in our system catalog data, plus a
bunch of work for whomever ends up being the one to want to push us
over. The other approach would be to make the ACL system understand
that not every privilege applies to every object, but that's would also
be a bunch of work (most likely more...).

Thanks!

Stephen

On 2/27/17 22:10, Stephen Frost wrote:

Peter,

* Peter Eisentraut (peter.eisentraut@2ndquadrant.com) wrote:

On 2/18/17 18:06, Stephen Frost wrote:

I'm not convinced that it really makes sense to have PUBLICATION of a
table be independent from the rights an owner of a table has. We don't
allow other ALTER commands on objects based on GRANT'able rights, in
general, so I'm not really sure that it makes sense to do so here.

The REFERENCES and TRIGGER privileges are very similar in principle.

TRIGGER is a great example of an, ultimately, poorly chosen privilege to
GRANT away, with a good history of discussion about it:

/messages/by-id/21827.1166115978@sss.pgh.pa.us
/messages/by-id/7389.1405554356@sss.pgh.pa.us

Those discussions about the trigger privileges are valid, but the actual
reason why this is a problem is because our trigger implementation is
broken by default. In the SQL standard, triggers are executed as the
table owner, so the trigger procedure does not have full account access
to the role that is causing the trigger to fire. This is an independent
problem that deserves consideration, but it does not invalidate the kind
of privilege that can be granted.

Then you couldn't set up a replication structure involving tables owned
by different users without resorting to blunt instruments like having
everything owned by the same user or using superusers.

That's not correct- you would simply need a user who is considered an
owner for all of the objects which you want to replicate, that doesn't
have to be a *direct* owner or a superuser.

The tables can have individual roles, with some admin role who is a
member of those other roles, or another mechanism (as Simon has proposed
not too long ago...) to have a given role be considered equivilant to an
owner for all of the relations in a particular database.

I'm not really following what you are saying here. It seems to me that
you are describing a new kind of facility that gives a role a given
capability with respect to a table.

If so, we already have that, namely privileges. If not, please elaborate.

--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 3/3/17 10:07, Stephen Frost wrote:

Will users really understand that the PUBLISH right actually allows
complete access to the entire relation, rather than just the ability for
a user to PUBLISH what they are currently about to SELECT? It certainly
doesn't seem intuitive to me, which is why I am concerned that it's
going to lead to confusion and bug/security reports down the road, or,
worse, poorly configured systems.

Well, this is a new system with its own properties, which is why I'm
proposing a new way to manage access. If it were just the same as the
existing stuff, we wouldn't need this conversation. I'm interested in
other ideas.

--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 10/03/17 20:02, Peter Eisentraut wrote:

On 2/27/17 22:10, Stephen Frost wrote:

Peter,

* Peter Eisentraut (peter.eisentraut@2ndquadrant.com) wrote:

On 2/18/17 18:06, Stephen Frost wrote:

I'm not convinced that it really makes sense to have PUBLICATION of a
table be independent from the rights an owner of a table has. We don't
allow other ALTER commands on objects based on GRANT'able rights, in
general, so I'm not really sure that it makes sense to do so here.

The REFERENCES and TRIGGER privileges are very similar in principle.

TRIGGER is a great example of an, ultimately, poorly chosen privilege to
GRANT away, with a good history of discussion about it:

/messages/by-id/21827.1166115978@sss.pgh.pa.us
/messages/by-id/7389.1405554356@sss.pgh.pa.us

Those discussions about the trigger privileges are valid, but the actual
reason why this is a problem is because our trigger implementation is
broken by default. In the SQL standard, triggers are executed as the
table owner, so the trigger procedure does not have full account access
to the role that is causing the trigger to fire. This is an independent
problem that deserves consideration, but it does not invalidate the kind
of privilege that can be granted.

Then you couldn't set up a replication structure involving tables owned
by different users without resorting to blunt instruments like having
everything owned by the same user or using superusers.

That's not correct- you would simply need a user who is considered an
owner for all of the objects which you want to replicate, that doesn't
have to be a *direct* owner or a superuser.

The tables can have individual roles, with some admin role who is a
member of those other roles, or another mechanism (as Simon has proposed
not too long ago...) to have a given role be considered equivilant to an
owner for all of the relations in a particular database.

I'm not really following what you are saying here. It seems to me that
you are describing a new kind of facility that gives a role a given
capability with respect to a table.

If so, we already have that, namely privileges. If not, please elaborate.

My understanding of what Shephen is proposing is, you have "ownerA" of
tableA and "ownerB" of tableB, then you want role "publishe"r to be able
to publish those, so you simply grant it the "ownerA" and "ownerB"
roles. Obviously that might is many situations mean that the "publisher"
role potentially also gets sweeping privileges to other tables which may
not be desirable.

--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Tue, Mar 14, 2017 at 2:41 PM, Petr Jelinek
<petr.jelinek@2ndquadrant.com> wrote:

My understanding of what Shephen is proposing is, you have "ownerA" of
tableA and "ownerB" of tableB, then you want role "publishe"r to be able
to publish those, so you simply grant it the "ownerA" and "ownerB"
roles. Obviously that might is many situations mean that the "publisher"
role potentially also gets sweeping privileges to other tables which may
not be desirable.

I didn't hear Stephen propose that "publish" should be a
role-attribute, and I don't understand why that would be a good idea.
Presumably, we don't want unprivileged users to be able to fire up
logical replication because that involves making connections to other
systems from the PostgreSQL operating system user's account, and that
should be a privileged operation. But that's the subscriber side, not
the publisher side.

I don't otherwise follow Stephen's argument. It seems like he's
complaining that PUBLISH might give more access to the relation than
SELECT, but, uh, that's what granting additional privileges does in
general, by definition. Mostly we consider that a feature, not a bug.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 14/03/17 19:47, Robert Haas wrote:

On Tue, Mar 14, 2017 at 2:41 PM, Petr Jelinek
<petr.jelinek@2ndquadrant.com> wrote:

My understanding of what Shephen is proposing is, you have "ownerA" of
tableA and "ownerB" of tableB, then you want role "publishe"r to be able
to publish those, so you simply grant it the "ownerA" and "ownerB"
roles. Obviously that might is many situations mean that the "publisher"
role potentially also gets sweeping privileges to other tables which may
not be desirable.

I didn't hear Stephen propose that "publish" should be a
role-attribute, and I don't understand why that would be a good idea.
Presumably, we don't want unprivileged users to be able to fire up
logical replication because that involves making connections to other
systems from the PostgreSQL operating system user's account, and that
should be a privileged operation. But that's the subscriber side, not
the publisher side.

I don't otherwise follow Stephen's argument. It seems like he's
complaining that PUBLISH might give more access to the relation than
SELECT, but, uh, that's what granting additional privileges does in
general, by definition. Mostly we consider that a feature, not a bug.

Not what I mean - owner should be able to publish table. If you are
granted role of the owner you can do what owner can no? That's how I
understand Stephen's proposal.

--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 14/03/17 19:49, Petr Jelinek wrote:

On 14/03/17 19:47, Robert Haas wrote:

On Tue, Mar 14, 2017 at 2:41 PM, Petr Jelinek
<petr.jelinek@2ndquadrant.com> wrote:

My understanding of what Shephen is proposing is, you have "ownerA" of
tableA and "ownerB" of tableB, then you want role "publishe"r to be able
to publish those, so you simply grant it the "ownerA" and "ownerB"
roles. Obviously that might is many situations mean that the "publisher"
role potentially also gets sweeping privileges to other tables which may
not be desirable.

I didn't hear Stephen propose that "publish" should be a
role-attribute, and I don't understand why that would be a good idea.
Presumably, we don't want unprivileged users to be able to fire up
logical replication because that involves making connections to other
systems from the PostgreSQL operating system user's account, and that
should be a privileged operation. But that's the subscriber side, not
the publisher side.

I don't otherwise follow Stephen's argument. It seems like he's
complaining that PUBLISH might give more access to the relation than
SELECT, but, uh, that's what granting additional privileges does in
general, by definition. Mostly we consider that a feature, not a bug.

Not what I mean - owner should be able to publish table. If you are
granted role of the owner you can do what owner can no? That's how I
understand Stephen's proposal.

Note that I am not necessarily saying it's better though, just trying to
explain. It definitely has drawbacks, as in order to grant publish on
one table you might be granting lots of privileges on various objects by
granting the role. So for granularity purposes Peter's PUBLISH privilege
for tables sounds better to me.

--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Greetings,

* Petr Jelinek (petr.jelinek@2ndquadrant.com) wrote:

On 14/03/17 19:47, Robert Haas wrote:

On Tue, Mar 14, 2017 at 2:41 PM, Petr Jelinek
<petr.jelinek@2ndquadrant.com> wrote:

My understanding of what Shephen is proposing is, you have "ownerA" of
tableA and "ownerB" of tableB, then you want role "publishe"r to be able
to publish those, so you simply grant it the "ownerA" and "ownerB"
roles. Obviously that might is many situations mean that the "publisher"
role potentially also gets sweeping privileges to other tables which may
not be desirable.

I didn't hear Stephen propose that "publish" should be a
role-attribute, and I don't understand why that would be a good idea.
Presumably, we don't want unprivileged users to be able to fire up
logical replication because that involves making connections to other
systems from the PostgreSQL operating system user's account, and that
should be a privileged operation. But that's the subscriber side, not
the publisher side.

I don't otherwise follow Stephen's argument. It seems like he's
complaining that PUBLISH might give more access to the relation than
SELECT, but, uh, that's what granting additional privileges does in
general, by definition. Mostly we consider that a feature, not a bug.

Not what I mean - owner should be able to publish table. If you are
granted role of the owner you can do what owner can no? That's how I
understand Stephen's proposal.

Exactly correct, yes. I was not suggesting it be a role attribute.

If we move forward with making PUBLISH a GRANT'able option then I do
worry that people will be surprised that PUBLISH gives you more access
to the table than a straight SELECT does. We have a good deal of
granularity in what a user can GRANT'd to see and PUBLISH completely
ignores all of that.

The way I see PUBLISH, it's another command which is able to read from a
table, not unlike the way COPY works, but we don't have an independent
COPY privilege and the COPY command does actually respect the SELECT
privileges on the table.

Another approach to solving my concern would be to only allow the
publishing of tables by non-owner users who have table-level SELECT
rights (meaning they can see all columns of the table) and which don't
have RLS enabled.

Frankly, though, I really don't buy the argument that there's a serious
use-case for non-owners to be GRANT'd the PUBLISH capability, which
means we would end up burning one of the few remaining privilege bits
for something that isn't going to be used and I don't care for that
either.

Thanks!

Stephen

On Tue, Mar 14, 2017 at 2:56 PM, Petr Jelinek
<petr.jelinek@2ndquadrant.com> wrote:

Note that I am not necessarily saying it's better though, just trying to
explain. It definitely has drawbacks, as in order to grant publish on
one table you might be granting lots of privileges on various objects by
granting the role. So for granularity purposes Peter's PUBLISH privilege
for tables sounds better to me.

I get that. If, without the patch, letting user X do operation Y will
require either giving user X membership in a role that has many
privileges, and with the patch, will require only granting a specific
privilege on a specific object, then the latter is obviously far
better from a security point of view.

However, what I'm not clear about is whether this is a situation
that's likely to come up much in practice. I would have thought that
publications and subscriptions would typically be configured by roles
with quite high levels of privilege anyway, in which case the separate
PUBLISH privilege would rarely be used in practice, and might
therefore fail to be worth using up a bit. I might be missing a
plausible scenario in which that's not the case, though.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Greetings,

* Robert Haas (robertmhaas@gmail.com) wrote:

However, what I'm not clear about is whether this is a situation
that's likely to come up much in practice. I would have thought that
publications and subscriptions would typically be configured by roles
with quite high levels of privilege anyway, in which case the separate
PUBLISH privilege would rarely be used in practice, and might
therefore fail to be worth using up a bit. I might be missing a
plausible scenario in which that's not the case, though.

Right, this is part of my concern also.

Further, PUBLISH, as I understand it, is something of a one-time or at
least reasonably rarely done operation. This is quite different from a
SELECT privilege which is used on every query against the table and
which may be GRANT'd to user X today and user Y tomorrow and perhaps
REVOKE'd from user X the next day.

What happens when the PUBLISH right is REVOKE'd from the user who did
the PUBLISH in the first place, for example..?

Thanks!

Stephen

On 14/03/17 20:09, Robert Haas wrote:

On Tue, Mar 14, 2017 at 2:56 PM, Petr Jelinek
<petr.jelinek@2ndquadrant.com> wrote:

Note that I am not necessarily saying it's better though, just trying to
explain. It definitely has drawbacks, as in order to grant publish on
one table you might be granting lots of privileges on various objects by
granting the role. So for granularity purposes Peter's PUBLISH privilege
for tables sounds better to me.

I get that. If, without the patch, letting user X do operation Y will
require either giving user X membership in a role that has many
privileges, and with the patch, will require only granting a specific
privilege on a specific object, then the latter is obviously far
better from a security point of view.

However, what I'm not clear about is whether this is a situation
that's likely to come up much in practice. I would have thought that
publications and subscriptions would typically be configured by roles
with quite high levels of privilege anyway, in which case the separate
PUBLISH privilege would rarely be used in practice, and might
therefore fail to be worth using up a bit. I might be missing a
plausible scenario in which that's not the case, though.

Yeah that's rather hard to say in front. Maybe safest action would be to
give the permission to owners in 10 and revisit special privilege in 11
based on feedback?

--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Tue, Mar 14, 2017 at 3:37 PM, Petr Jelinek
<petr.jelinek@2ndquadrant.com> wrote:

On 14/03/17 20:09, Robert Haas wrote:

On Tue, Mar 14, 2017 at 2:56 PM, Petr Jelinek
<petr.jelinek@2ndquadrant.com> wrote:

Note that I am not necessarily saying it's better though, just trying to
explain. It definitely has drawbacks, as in order to grant publish on
one table you might be granting lots of privileges on various objects by
granting the role. So for granularity purposes Peter's PUBLISH privilege
for tables sounds better to me.

I get that. If, without the patch, letting user X do operation Y will
require either giving user X membership in a role that has many
privileges, and with the patch, will require only granting a specific
privilege on a specific object, then the latter is obviously far
better from a security point of view.

However, what I'm not clear about is whether this is a situation
that's likely to come up much in practice. I would have thought that
publications and subscriptions would typically be configured by roles
with quite high levels of privilege anyway, in which case the separate
PUBLISH privilege would rarely be used in practice, and might
therefore fail to be worth using up a bit. I might be missing a
plausible scenario in which that's not the case, though.

Yeah that's rather hard to say in front. Maybe safest action would be to
give the permission to owners in 10 and revisit special privilege in 11
based on feedback?

I think that would be entirely sensible.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 3/14/17 15:05, Stephen Frost wrote:

Another approach to solving my concern would be to only allow the
publishing of tables by non-owner users who have table-level SELECT
rights

An early version of the logical replication patch set did that. But the
problem is that this way someone with SELECT privilege could include a
table without replica identity index into a publication and thereby
prevent updates to the table. There might be ways to tweak things to
make that work better, but right now it works that way.

--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 3/14/17 15:37, Petr Jelinek wrote:

Yeah that's rather hard to say in front. Maybe safest action would be to
give the permission to owners in 10 and revisit special privilege in 11
based on feedback?

I'm fine with that.

--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 3/14/17 14:49, Petr Jelinek wrote:

Not what I mean - owner should be able to publish table. If you are
granted role of the owner you can do what owner can no?

I didn't actually know that ownership worked that way. You can grant
the role of an owner to someone, and then that someone has ownership
rights. So that should satisfy a pretty good range of use cases for who
can publish what tables.

--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers