Re: type privileges and default privileges

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: type privileges and default privileges
Date: 2011-11-11 14:39:47
Message-ID: 20111111143947.GM24234@tamriel.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

* Robert Haas (robertmhaas(at)gmail(dot)com) wrote:
> Oh, I didn't realize that you were proposing a database-wide setting;
> my point was just that the way the feature looks to the user doesn't
> have to dictate the catalog representation.

I agree that the features don't have to define the catalog
representation. On the other hand, I don't think we'd want a change to
the 'default defaults' to affect existing objects in the system.

> I'm not entirely certain whether a database-wide setting is useful
> enough to justify the additional complexity. I'm not saying it isn't,
> just wondering out loud. To need this rather than just a per-schema
> facility, you'd need to be using enough schemas (or creating new ones
> frequently enough) that setting the privileges one schema at a time
> would be inconvenient. How common is that?

I don't really see it as a frequency thing, to be honest.. I see it as
dependent on the user base and what the users are allowed to do. I run
quite a few different databases with different roles. I've also got
lots of users that aren't DBAs but need to be able to create tables,
sometimes create schemas, etc. What typically ends up happening is that
they'll create a schema and be running along happily, until one day
they're out, and someone else needs to do something with that schema.
Then it's a support request to me, even though that schema should have
had 'usage' to public from the get-go because there's nothing sensetive
in that database. I've got cases where the user who created the schema
doesn't know how or doesn't think they can change the permissions
themselves too, more calls to me.

Being able to set up the defaults on the database when we create it
(that's not something we let non-admins do, at least.. :), depending on
what the role of the new database is, would be quite nice. Being able
to do it for certain objects in schemas has certainly helped. Doing it
for more objects (like schemas) seems like a natural next-step to me.
Doing it for schemas is inherently "database-wide", as that's the
container which schemas exist inside of. Thinking on it a bit more,
the 'database-wide' options for objects which exist inside schemas could
just be what new schemas are initialized with for their defaults using
the existing system. If schemas are created before that's done, there'd
be a bit of pain going back and updating them, but that's not a big
deal, imv.

I do still think it'd be nice if we displayed the *actual* ACLs in \dp
instead of just 'blank'. Also, do we really not sure a function's ACL
in any \df*..? :/

Thanks,

Stephen

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2011-11-11 14:40:29 Rename trace_userlocks? WAS Re: LOCK_DEBUG is busted
Previous Message Robert Haas 2011-11-11 14:07:33 why do we need two snapshots per query?