RUN() and a clean execution environment

I actually have what appears to be a decent way to prevent the file access, but would prefer something more... definitive.

You can include in the name of the source files in the original package characters that BrightScript can't read (e.g. "?"), and then no access of the file seems to work from within BrightScript.

We do not currently have any plans to restrict access to the pkg:/ contents within Run(). You should only try to Run() code that you trust (maybe via ssl mutual auth with roku-x-reserved-header).

Is there some special usage case I'm missing?

--Kevin

"RokuKevin" wrote:
We do not currently have any plans to restrict access to the pkg:/ contents within Run(). You should only try to Run() code that you trust (maybe via ssl mutual auth with roku-x-reserved-header).

Is there some special usage case I'm missing?

Vetted third party code. While reviewed, flagged and scrubbed, it's possible to miss possible access of original pkg:/ files (human error), and I'm trying to provide a high level of assurance. If the code in question is dynamically downloaded and run over a secure system, it itself becomes the weak. There's no way to definitively secure your access methods if he source defining those methods can be accessed and posted to a remote location.

I'll admit it's a fairly limited use case, and I've got a full system defined (policy, manual review, hard limits in current language capabilities) to prevent that access, but a definitive way not based on a current language limitation would be better than relying on just that limitation and code review (which would be used regardless of the Roku's ability to chroot code).

I believe my current methods DO provide a high level of assurance (you can get quite far through flagging certain language features as off limits or requiring quite a bit more thorough review), but the more blocks in place the better.