Re: [Koha-devel] SQL reports [error]
At 05:44 PM 4/30/2012 +0200, Fischer, Katrin wrote:
I really donât like the idea. I think if you want someone to make changes to the database, you should give them a proper tool and training to do that (outside of Koha).
Respectfully, we might be talking apples and oranges. *All* staff and many users "make changes to the database" - not fundamental structural changes, but add, modify and delete data records. And it was the latter point that I raised earlier today. You are of course correct that the various options allowed by UPDATE, DELETE, DROP, INSERT, and CREATE *can* modify/damage the structure of your database; but they can also be incredibly useful (see my earlier email that uses UPDATE.) I don't know how you are setup, but in my organization for any intervention that requires CLI, I personally have to go to our server room (I am the only keyholder) as I have locked the Koha server down fairly tightly from remote access. I decide (after consultation with staff/volunteers) what scripts can|cannot be used in the "normal course of business." I have tested a certain script required by staff (hundreds of times every year) by running it some seventy times to ensure it does what it is supposed to and does not do anything else. It is ready to go into useful production, but "as-is" Koha 3.6 does not allow me to make it available to staff -- and every time they need it (ad hoc basis) it takes me ten minutes, instead of staff "clicking a button." This is because the design of Koha includes very well-intentioned, but arbitrary nonetheless, hard code denying the use of UPDATE. The chances of a major catastrophe are much greater if I try and train our cataloguers in the intricacies of MySQL and allow them access to the server room, than if I develop a secure script and make it available on the staff interface -- and that was the only reason I raised it on this list and will implement it on our Koha server. YMMV. Best - Paul
The interface for statistics is very limited and does not give feedback when your SQL statements have errors or produce no result sets. Also it seems like a big security risk to me.
Katrin
From: koha-devel-bounces@lists.koha-community.org [mailto:koha-devel-bounces@lists.koha-community.org] On Behalf Of Jared Camins-Esakov Sent: Monday, April 30, 2012 5:21 PM To: Paul Poulain Cc: koha-devel@lists.koha-community.org Subject: Re: [Koha-devel] SQL reports [error]
Paul,
On Mon, Apr 30, 2012 at 11:17 AM, Paul Poulain <paul.poulain@biblibre.com> wrote:
Question to all = could it be a good idea to let superlibrarians execute dangerous SQLs like the one forbidden by the test ? Otherwise asked: could we add a unless permission eq 'superlibrarian' condition ?
( ie: "with great power comes great responsibility" -@spiderman uncle- )
We were actually just discussing that on #koha a few days ago. I argued that only the database user (i.e. user 0) should be allowed to do it. If you have the direct login, there's nothing you can't do with the system just by logging into the database.
Regards,
Jared
-- Jared Camins-Esakov
Bibliographer, C & P Bibliography Services, LLC
(phone) +1 (917) 727-3445
(e-mail) jcamins@cpbibliography.com
On Mon, Apr 30, 2012 at 12:51 PM, Paul <paul.a@aandc.org> wrote:
At 05:44 PM 4/30/2012 +0200, Fischer, Katrin wrote:
I really don’t like the idea. I think if you want someone to make changes to the database, you should give them a proper tool and training to do that (outside of Koha).
Respectfully, we might be talking apples and oranges. *All* staff and many users "make changes to the database" - not fundamental structural changes, but add, modify and delete data records. And it was the latter point that I raised earlier today.
True, except *all* staff and many users do not have the capability to arbitrarily or otherwise create SQL which modifies and makes changes to the database.
You are of course correct that the various options allowed by UPDATE, DELETE, DROP, INSERT, and CREATE *can* modify/damage the structure of your database; but they can also be incredibly useful (see my earlier email that uses UPDATE.)
<snip>
The chances of a major catastrophe are much greater if I try and train our cataloguers in the intricacies of MySQL and allow them access to the server room, than if I develop a secure script and make it available on the staff interface -- and that was the only reason I raised it on this list and will implement it on our Koha server. YMMV.
What you are asking to be placed into the main repo is contradictory to security best practices. I would humbly suggest that you do just what you have done/propose to do: modify your local installation to meet your local requirements and security tolerance levels. However, let's leave the main-line code in stricter compliance with the security norms of the larger community. Having said that, you might consider coding up a custom "tool" and place it in Koha's tools page which does what you want. Then you could follow Koha's typical practices for such db interaction, including adding the proper granular perms to control user access. Kind Regards, Chris
participants (2)
-
Chris Nighswonger -
Paul