Even using GRANT to set up a userid with limited privileges, you are still vunerable to people setting values manually rather than those your script derives.

I was going to suggest having a server application running on your Debian box that receives the values from the script on the client and have it make the updates to the database, but the unscrupulous people you fear could still send bad data.

The only reasonably secure way I can think of is to have the client script only send the inputs gathered at the client and the have the server do whatever process your client script currently does to derive the values for update and then make them.

This way, all the important information, userid/password, database, tables, and field names are all kept private in a script that the user should never be able to see.

Personally, rather than writing a full client-server, two-way traffic application which can be hard--especially the culling of CLOSE-WAIT bound child processes at the server end--I'd have two userids.

One with read-only privileges would be used by your client application--with userid/password embedded as now--to request data as needed and let the DBM take care of the multi-user aspects of things.

The second would have the write privileges and be used by a server app, that listens on a single port and only allows a single connection at a time. It would sit blocking until it received a packet of input, do what ever manipulation and validation that part of your current client uses and then perform the update, and go back to waiting.

Where your existing client code currently connects to MySQl, it would connect to the server port, fire the data in a UDP packet and close the port. If it couldn't connect because the server was busy, just sleep rand*5; and try again.

You should still do the validation of the data at the client end so that it doesn't need to get confirmation from the server, but you should send the raw input to the server and have it revalidate to make it harder for people to send spurious values into the DBM.

It's not a bulletproof solution, but I think will prevent anything other than the most determined attempts to supply fraudulent data and it should be relatively simple to implement as it would just reuse most of the code you already have.

Sending a UDP packet with LWP is very easy, and writing a wait-read-validate-update-loop server it not much harder.