[mythtv] Patch for generic SQL query
Kevin Kuphal
kuphal at dls.net
Wed Apr 27 17:36:04 UTC 2005
David Shay wrote:
>----- Original Message -----
>From: "Kevin Kuphal" <kuphal at dls.net>
>
>
>>>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...
>
>
>
I think for me, while it is a hole that should be considered, it is also
about a good design.
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
More information about the mythtv-dev
mailing list