Greetings, * Tom Lane (t...@sss.pgh.pa.us) wrote: > > ... and that backs up my position that we are setting up this > > privilege at the wrong level by using a default role which a superuser must > > grant independently from DB ownership. > > Don't see how this follows. It's somewhat accidental I think that > the existing behavior is tied to DB ownership. That's just because > at the time, that's the only sort of privilege we had that seemed > intermediate between superuser and Joe User. If we were designing > the behavior today, with default roles already a done deal for > handing out possibly-dangerous privileges, I think there's no > question that we'd be setting up this privilege as a default role > rather than tying it to DB ownership. We don't make DB ownership > a prerequisite to creating other sorts of functions, yet other > functions can be just as dangerous in some cases as C functions.
I suppose I'll just have to say that I disagree. I see a lot of value in having a level between superuser and Joe User, and DB owner looks pretty natural as exactly that, particularly for creating database-level objects like extensions. If anything, I tend to think we need more levels, not less- like a level that's "cluster owner" or something along those lines, that's also independent from "superuser" but would allow creating of cluster-level objects like databases and roles (with the right to then GRANT the ability to create those objects to other roles, if they wish). I don't really see default roles as a better alternative to a privilege hierarchy, but rather as a way for controlling access to things that don't really fall into the hierarchy. Maybe for cluster-level things like what I hint at above they'd be better, but for database-level objects, where you might decide you want to give a user access to create something in database X but not in database Y? Doesn't seem to fit very well to me. Thanks, Stephen
signature.asc
Description: PGP signature
