Re: It's time to support GRANT SELECT,UPDATE,...,...,... ON database.* to username

On Tue, 2007-10-02 at 12:06 -0400, Chris Browne wrote:
> It has tended to turn into recommendations to "write a function"
> because the desired functionality is almost never a constant. People
> *claim* that they want to grant access to everything, but there are
> commonly exceptions.
>
> "Oh, but that table needs to be kept secure from the users..."
>
> - Does it cover all tables? Really?
> - How about views?
> - How about functions? Operators?
> - What about the security definer functions? Are they exceptions?
>
> - How to deal with the exceptions that there are sure to be?
>

I think that <database>.* would be a bad idea, but a macro for
<schema>.* might not be so bad.

There are already different GRANT commands for TABLE, FUNCTION, SCHEMA,
SEQUENCE, etc.

I'm sure there are exceptions that would not be covered by such a blunt
tool, but granularity is not the point of this feature.

> The trouble is that "GRANT ON *.*" seems to be a lazy shortcut for
> someone who *thinks* they're trying to secure their system, but that
> would rather say "well, everything" as opposed to looking at things
> properly.
>
> That is, if you don't know what tables and other objects need to be
> secured, how can you have any idea that you're handling the securing
> of your application properly???

A reasonable use case for this feature would be adding a read-only
reporting role that needs access to a group of tables that all happen to
be within a schema.

This isn't critical, but for people who use an ORM that don't want to
think about the database, it's handy.

That being said, I'm not volunteering to write it, especially not in
response to a rude request.

Regards,
Jeff Davis