On 08/28/2012 10:42 PM, Tom Lane wrote:
Andrew Dunstan <and...@dunslane.net> writes:
On 08/28/2012 09:09 PM, Craig Ringer wrote:
Wouldn't that render the user utterly unable to do anything until you
added a bunch of GRANTs on the system catalogs for that user or a
group they're a member of?
Try it and see. You can do a lot without having any access rights at all
to the catalog tables.
Craig's got a really good point though: if we had the ability to "revoke
public", it would mean that something as simple as "SELECT 2+2" would
stop working. Or at least it ought to, since execute permissions on
int4pl() are granted to PUBLIC, and the proposal is for the role to not
have such permissions.
While you can in fact do a lot without any explicit catalog access,
I doubt that anyone will get far without the ability to use "+", "=",
"count()", etc. So that sounds like a killer argument from here.
The only way you would end up with a usable database is if you somehow
said "well, I didn't really mean that for built-in objects" ... but at
that point I think you have to stop asking to change the behavior of the
PUBLIC role. Instead make your own user-defined role that includes all
your users except for the locked-down roles, and grant permissions on
your non-system objects to that role not PUBLIC.
Yeah, what I've done in the past is revoke public privs from the catalog
tables and the information schema, and granted them to a pseudo-public
role. This has left intact the public privs of things like int4pl().
This works quite well for hiding schema details from a non-member of the
pseudo-public role, which was the aim. But if you want a user truly only
able to use some specified functions, say, maybe you would revoke the
lot. That's a fairly paranoid security model, but not beyond imagining.
(None of this is to say I think David's suggestion is a good one.)
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
