Greetings,
* David Christensen (david.christensen@crunchydata.com) wrote:
> On Tue, Nov 9, 2021 at 9:55 AM Mark Dilger <mark.dilger@enterprisedb.com> wrote:
> > > On Nov 9, 2021, at 7:36 AM, David Christensen <
> > david.christensen@crunchydata.com> wrote:
> > > If CINE semantics are at issue, what about the CREATE OR REPLACE
> > semantics with some sort of merge into the existing role? I don't care
> > strongly about which approach is taken, just think the overall "make this
> > role exist in this form" without an error is useful in my own work, and
> > CINE was easier to implement as a first pass.
> >
> > CREATE OR REPLACE might be a better option, not with the "merge into the
> > existing role" part, but rather as drop+create. If a malicious actor has
> > already added other roles to the role, or created a table with a malicious
> > trigger definition, the drop part will fail, which is good from a security
> > viewpoint. Of course, the drop portion will also fail under other
> > conditions which don't entail any security concerns, but maybe they could
> > be addressed in a series of follow-on patches?
> >
> > I understand this idea is not as useful for creating idempotent scripts,
> > but maybe it gets you part of the way there?
>
> Well, the CREATE OR REPLACE via just setting the role's attributes
> explicitly based on what you passed it could work (not strictly DROP +
> CREATE, in that you're keeping existing ownerships, etc, and can avoid
> cross-db permissions/ownership checks). Seems like some sort of merge
> logic could be in order, as you wouldn't really want to lose existing
> permissions granted to a role, but you want to ensure that /at least/ the
> permissions granted exist for this role.
What happens with role attributes that aren't explicitly mentioned
though? Do those get reset to 'default' or are they left as-is?
I suspect that most implementations will end up just explicitly setting
all of the role attributes, of course, because they want the role to
look like how it is defined to in whatever manifest is declaring the
role, but we should still think about how we want this to work if we're
going in this direction.
In terms of least-surprise, I do tend to think that the answer is "only
care about what is explicitly put into the command"- that is, if it
isn't in the CREATE ROLE statement then it gets left as-is. Not sure
how others feel about that though.
Thanks,
Stephen
