----- Original Message ----- From: "Kevin Kuphal" <[EMAIL PROTECTED]> > >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... And again, if you are security conscious, even about the existing risks of the mythtv protocol, you could easily add some firewall/iptables rules to only allow connections on port 6543 from authorized frontends. For me, and I would expect most users, I only have the users in my home to worry about. My router protects me from the outside world/internet. _______________________________________________ mythtv-dev mailing list [email protected] http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
