Re: Superowners

Simon,

* Simon Riggs (simon(at)2ndquadrant(dot)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 (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> Simon Riggs <simon(at)2ndquadrant(dot)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