David Shay wrote:
----- Original Message ----- From: "Kevin Kuphal" <[EMAIL PROTECTED]>I think for me, while it is a hole that should be considered, it is also about a good design.
what security is associated with this? is it a mechanism for injecting malicious SQL into the db?
This was my first thought as well. Why not add the individual commands as needed to support the functions of the remote frontends rather than opening up a big hole with unresticted SQL via the protocol.
Kevin
One goal was to reduce creating many, many new protocol commands to simply read portions of data out of existing tables. For really high-volume use cases, I would add a new protocol command.
I must be thick, because I just don't see this as a big hole. The limits of what this command could do are limited by whatever the mythtv sql user can do. While that could be damaging, I don't really see it as any more damaging than what you could do with the protocol today if you had malicious intent -- for example deleting every single recording, stopping recordings, shutting down mythbackend. I'm not sure that I could care about the database damage if all of my recordings were deleted...
Lots and lots of commands make more sense to me from a protocol standpoint than a single command to inject SQL. By having those commands as part of the protocol, mythfrontend and mythweb can also be modified to use them, providing a completely standard and repeatable method of accessing those structures in the database. If a bug is found in those methods, changing it in the backend protocol handler fixes it for all frontends whereas, allowing each of them to create their own SQL, results in situations like with MythWeb where new features are added to the mythfrontend using SQL and someone has to recreate the wheel for MythWeb to achieve the same functionality.
While adding individual commands maybe tedious, I think the advantages for all the mythtv clients are worthwhile. The mvmpc and mythroku teams will not have to both create the same code to access our structures and then maintain them as they change. Instead, the coding is inside the backend where it is maintained once for all projects and simply utilized by the client, making the client even thinner and simpler.
Kevin _______________________________________________ mythtv-dev mailing list [email protected] http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
