Simon, * Simon Riggs (si...@2ndquadrant.com) wrote: > So I was thinking about various annoying admin/security issues > recently, so I came up with this: a new type of user called a > “superowner”. It’s somewhere between a superuser and a normal user.
I like the general idea, but I'm not really thrilled with the name (too easy to confuse with superuser and people might, reasonably, assume 'superowner' can do more than 'superuser'), nor the proposed grammer- why have only one superowner? How does role membership play into this? > Superowner would own all objects defined by users, so it would do > useful things in contexts where superuser is not available. I also don't really like the idea of tossing out ownership-level rights for regular users. I would *much* rather have two independent concepts: - role attribute which makes a user be treated as if they own all normal-user-owned database objects (or perhaps as if they are a member of every role, which people have asked me for multiple times). - Managmenet of object ownership; as in, have a way to set a DEFAULT OWNER, or perhaps a FORCED OWNER. Setting DEFAULT OWNER would have the same requirments that ALTER TABLE ... OWNER TO requires today and we would re-check those rights at every object creation and error if we are unable to set the ownership requested (alternatively, we could allow it and just throw a warning, similar to what GRANT does when you try to GRANT something and GRANT doesn't end up actually doing anything). * Tom Lane (t...@sss.pgh.pa.us) wrote: > Simon Riggs <si...@2ndquadrant.com> writes: > > So I was thinking about various annoying admin/security issues > > recently, so I came up with this: a new type of user called a > > “superowner”. It’s somewhere between a superuser and a normal user. > > Superowner would own all objects defined by users, so it would do > > useful things in contexts where superuser is not available. > > What about just saying that the database owner has those privileges? I'm not thrilled with suddenly changing how a database owner works, though I'll admit that *new* users tend to assume things work more in this way. Thinking through it a bit more though, I can see why Simon is proposing that it be database-specific. That would seem to imply that what's needed is a per-database set of role attributes, ala pg_db_authid (not a great name, but the name can come later). Generally speaking, I like that idea as I can see other possible use-cases, in particular the question continues to come up about having a read-only user and being able to set that for a given role in a given database would be great (though I think it would also be nice to have one cluster-wide, but that goes for Simon's proposed feature here too, imv). > After all, the ultimate privilege of an owner is to drop the object > (and then remake it as she pleases), and the DB owner has that option > w.r.t. the whole database. So I'm not sure we need to invent a new > concept. I can see some overlap with that. > With or without it being a separate property, there's a point I think > you missed: this should only extend to objects owned by normal users, > not by superusers. Otherwise there are all sorts of security issues. Agreed. Thanks! Stephen
Description: Digital signature