----- Original Message -----
> From: "Brent Clark" <brentgclarklist@stripped>
> I know the answer (well I think I do :) ), but im still going to ask.
> What is the risk if do the "GRANT ALL PRIVILEGES ON *.* TO 'root'@'%'
> IDENTIFIED BY 'mysql' WITH GRANT OPTION;"
> To satisfy the developer.
That said developer then has full privileges with that account, perhaps? :-)
Check what privileges the stored procedure REALLY needs, and create an account with a
strong, random password that has only those privileges. Do not give out the password to
the developer. Any developer that demands full admin privileges is not to be left within a
hundred miles of a production server.
Developers get full DML rights on the dev environment. They're free to fuck up their own
database as much as they want, there.
If you have the comfort of a staging environment, they get
select/insert/update/delete/execute to start off. More may be added depending on what is
needed. Document the strict minimum privileges that make stuff work. Repeated requests for
more privileges will be met with a frown, but granted. You *should* know what privileges
you need, you wrote the damn thing.
If you have the luxury of a preproduction environment, only the privileges documented from
staging will be granted. Requests for additional privileges will be met with a thorough
LARTing and a nuking of the account and data. Redo from start.
On production, installs are performed strictly as per procedure; no exceptions; and only
from the scripts that I have documented as working on preprod. You don't even get access
to a mysql client on the app server. If a dump to dev is *really* not good enough for you
to debug an issue, you can sit next to me while I query the database for you.
Also, @John Siebert, DEFINER privileges define with which privileges the SP will execute,
whereas it is the user invoking the SP who needs execute privileges on it.
Bier met grenadyn
Is als mosterd by den wyn
Sy die't drinkt, is eene kwezel
Hy die't drinkt, is ras een ezel