<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The users dont have access to the Myth Protocol, only XBMC Does!<br>
</blockquote>
<br>
You do realize that if users can run XBMC which speaks to mythbackend over the internal protocol, they can run whatever the hell else they want to communicate using the internal protocol. Restrictions implemented client-side are absolutely meaningless when the user can run any client they choose. Security measures must be in place on the backend, and there are currently next to none. The protocol is unauthenticated, in plain text, and the only real protection measures anywhere in it are simple sanity checks to prevent clients from breaching the boundaries of the storage path roots.<br>


</blockquote>
<br></div>
So running Myth Frontend has the same issues, or any other machine on the same network.</blockquote><div><br></div><div>What Raymond is saying is that if the myth protocol is exposed, then anyone can utilize it to do anything that the protocol is capable of doing.  The only way I could imagine you could restrict access while still using the mythprotocol would be to write some sort of proxy for it that only passes certain requests through.</div>

<div><br></div><div>However you could easily block the myth protocol altogether with a firewall, and only allow access to the system via DLNA (uPNP), or read-only NFS.  You could password protect mythweb to manage recordings, or run the frontend on the server.</div>

</div></div>