Re: Default Roles (was: Additional role attributes)
От | Stephen Frost |
---|---|
Тема | Re: Default Roles (was: Additional role attributes) |
Дата | |
Msg-id | 20150513030721.GK30322@tamriel.snowman.net обсуждение исходный текст |
Ответ на | Re: Default Roles (was: Additional role attributes) (Stephen Frost <sfrost@snowman.net>) |
Ответы |
Re: Default Roles
Re: Default Roles (was: Additional role attributes) Re: Default Roles (was: Additional role attributes) |
Список | pgsql-hackers |
All, This patch gets smaller and smaller. Upon reflection I realized that, with default roles, it's entirely unnecssary to change how the permission checks happen today- we can simply add checks to them to be looking at role membership also. That's removed the last of my concerns regarding any API breakage for existing use-cases and has greatly simplified things overall. This does change the XLOG functions to require pg_monitor, as discussed on the other thread where it was pointed out by Heikki that the XLOG location information could be used to extract sensitive information based on what happens during compression. Adding docs explaining that is on my to-do list for tomorrow. * Stephen Frost (sfrost@snowman.net) wrote: > Andres suggested that we drop the REPLICATION role attribute and just > use membership in pg_replication instead. That's turned out quite > fantastically as we can now handle upgrades without breaking anything- > CREATE ROLE and ALTER ROLE still accept the attribute but simply grant > pg_replication to the role instead, and postinit.c has been changed to > check role membership similar to other pg_hba role membership checks > when a replication connection comes in. Hat's off to Andres for his > suggestion. It's also unnecessary to change how the REPLICATION role attribute functions today. This patch does add the pg_replication role, but it's only allowed to execute the various pg_logical and friends functions and not to actually connect as a REPLICATION user. Connecting as a REPLICATION user allows you to stream the entire contents of the backend, after all, so it makes sense to have that be independent. I added another default role which allows the user to view pg_show_file_settings, as that seemed useful to me. The diffstat for that being something like 4 additions without docs and maybe 10 with. More documentation would probably be good though and I'll look at adding to it. Most of the rest of what I've done has simply been reverting back to what we had. The patch is certainly far easier to verify by reading through it now, as the changes are right next to each other, and the regression output changes are much smaller. Thoughts? Comments? Suggestions? Thanks! Stephen
Вложения
В списке pgsql-hackers по дате отправления: