Hi Stuart, Can we get rid of per-script table permissions? Is there a significant benefit to this policy in terms of isolation. The bulk of our code runs in the app server with almost unlimited access to the DB.
There are significant costs to maintaining that policy: - In the sample of my critical analysis, DB permission errors were 6% of the critical bugs. - Just in the last weeks, we had DB permission problems occured 2 or 3 times. - We have several tests that only purpose is to create complex enough hierarchy of object to ensure that the script still runs without permission error. - We could probably simplify the deployment (since we'd only need to create and remove users, not permission group.) So I think to put up with such costs, the benefits have to be clear. And as I understand it currently, I don't think that's the case. On the other hand, I think maintaining the one-user per script policy is great for an auditing purpose, and doesn't cost us much to keep. Cheers -- Francis J. Lacoste francis.laco...@canonical.com
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
