Re: [HACKERS] logical replication access control patches

Поиск
Список
Период
Сортировка
От Stephen Frost
Тема Re: [HACKERS] logical replication access control patches
Дата
Msg-id 20170314190529.GU9812@tamriel.snowman.net
обсуждение исходный текст
Ответ на Re: [HACKERS] logical replication access control patches  (Petr Jelinek <petr.jelinek@2ndquadrant.com>)
Ответы Re: [HACKERS] logical replication access control patches  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Список 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

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Jeff Janes
Дата:
Сообщение: Re: [HACKERS] Authentication tests, and plain 'password'authentication with a SCRAM verifier
Следующее
От: Robert Haas
Дата:
Сообщение: Re: [HACKERS] logical replication access control patches