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

scott(dot)marlowe(at)gmail(dot)com ("Scott Marlowe") writes:
> About 75% of the time I see that response, it comes with the actual
> code to do just that. I.e. cut and paste and voila, you've got the
> functions.
>
>> You write the function. Fuck the standard and
>> wake up.
>
> Me? What about you? The fact is there's a limited number of hackers
> capable of writing what you're asking for cleanly and correctly, and
> they're working on other stuff. Asking them politely has been know to
> work. Using the F word not so much.

"Feel free to contribute build files. Or work on your motivational
skills, and maybe someone somewhere will write them for you..."
-- "Fredrik Lundh" <effbot(at)telia(dot)com>

This is the usual sort of *right* answer to this...

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?

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???
--
let name="cbbrowne" and tld="cbbrowne.com" in name ^ "@" ^ tld;;
http://linuxdatabases.info/info/nonrdbms.html
Should vegetarians eat animal crackers?