MySQL Forums
Forum List  »  Triggers

Re: Can a Trigger run a PHP file, and pass variables to it?
Posted by: RJ Herrick
Date: January 26, 2010 02:08PM

I know of two methods of executing system commands from mysql, trigger or otherwise. Both require some indirection, as there is no native method provided by the MySQL server.

One is to send the parameters to an outfile that is used as a queue by an external daemon (filemon, cron, etc). A security concern with this approach is that any user with FILE permission could set any arguments.

Another is to create a user-defined function that does the work directly. The MySQL UDF project @ provides some Swiss army chainsaws in the form of sys_eval() and sys_exec(). Perhaps these functions have a place in heavily secured, highly specialized dbs but you would be more secure with a custom function with a more limited utility.

Executing code through MySQL has serious security implications. Generally, the data or action performed will use the permissions of the user account running the server (see your OS for specifics.) You probably don't want that account to be able to do much that isn't related to running your server, so there is a limit to the utility of using a udf. Relying on FILE permission doesn't give you much granularity in ensuring the request is from an authorized source.

The safest way might be to create an outfile, whose existence signals a daemon monitoring for it. The daemon can then run a query that gathers the actual parameters off a properly secured queue table. This ensures that arbitrary code can't be executed and that the parameters used are authorized. The daemon runs through the queue table records and deletes the outfile at the end of its run.

Options: ReplyQuote

Written By
Re: Can a Trigger run a PHP file, and pass variables to it?
January 26, 2010 02:08PM

Sorry, you can't reply to this topic. It has been closed.

Content reproduced on this site is the property of the respective copyright holders. It is not reviewed in advance by Oracle and does not necessarily represent the opinion of Oracle or any other party.