Re: allowing for control over SET ROLE
От | Robert Haas |
---|---|
Тема | Re: allowing for control over SET ROLE |
Дата | |
Msg-id | CA+TgmoY3ZStmtErYccRtSXJpR6CRhNNqkKdr1aC9pKj04Uqyug@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: allowing for control over SET ROLE (Noah Misch <noah@leadboat.com>) |
Ответы |
Re: allowing for control over SET ROLE
|
Список | pgsql-hackers |
On Sat, Dec 31, 2022 at 1:16 AM Noah Misch <noah@leadboat.com> wrote: > On Thu, Nov 17, 2022 at 04:24:24PM -0800, Jeff Davis wrote: > > On Thu, 2022-11-17 at 16:52 -0500, Robert Haas wrote: > > > But I think the bigger reason is that, in my opinion, this proposal is > > > more generally useful, because it takes no position on why you wish to > > > disallow SET ROLE. You can just disallow it in some cases and allow it in > > > others, and that's fine. > > In this commit 3d14e17, the documentation takes the above "no position". The > implementation does not, in that WITH SET FALSE has undocumented ability to > block ALTER ... OWNER TO, not just SET ROLE. Leaving that undocumented feels > weird to me, but documenting it would take the position that WITH SET FALSE is > relevant to the security objective of preventing object creation like the > example in the original post of this thread. How do you weigh those > documentation trade-offs? In general, I favor trying to make the documentation clearer and more complete. Intentionally leaving things undocumented doesn't seem like the right course of action to me. That said, the pre-existing documentation in this area is so incomplete that it's sometimes hard to figure out where to add new information - and it made no mention of the privileges required for ALTER .. OWNER TO. I didn't immediately know where to add that, so did nothing. Maybe I should have tried harder, though. -- Robert Haas EDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: