Re: [HACKERS] Superowners

Simon,

* Simon Riggs (simon@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
theyare 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
OWNERwould have the same requirments that ALTER TABLE ... OWNER TO requires today and we would re-check those rights at
everyobject creation and error if we are unable to set the ownership requested (alternatively, we could allow it and
justthrow 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@sss.pgh.pa.us) wrote:
> Simon Riggs <simon@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