Re: [HACKERS] logical replication access control patches
От | Robert Haas |
---|---|
Тема | Re: [HACKERS] logical replication access control patches |
Дата | |
Msg-id | CA+TgmoZawQ=aQscSavH5bK0pEm2sNpiZwYoZuqKZJcm1xjPJog@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] logical replication access control patches (Petr Jelinek <petr.jelinek@2ndquadrant.com>) |
Список | 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
В списке pgsql-hackers по дате отправления: