Jamie Heilman wrote:

I'm trying to use the equivalent of a (mini) Script (Python) as an attribute of a Product I'm writing. I'm confused about how SecurityManager.addContext works though, and when I should use it. I'm far enough along in my product code that I'm able to write some code in a textarea, store that, compile it as a restricted python function, and execute it when I need to... but I'm not executing it in any sort of special context. I get the feeling I should be, though I'm not sure why. Is there any documentation on this stuff at all? Tucked away somewhere? The whole security policy stack, default methods, custom methods, its all rather nebulous for me at the moment and I don't particularly want to publish this product until I'm sure I'm doing the right thing.

The product is a cache manager, the restricted code represents the the function that aggregates the cache index, thus the function is executed whenever a cache get or set is done.

addContext() might be more appropriately called beginExecutable(). During execution of a restricted script, the security policy restricts privileges to the intersection of the user's roles and the roles of the owner of the executing script. addContext() tells the security policy which executable is currently running, and the security policy does the rest of the work of discovering the owner and roles. The idea is to prevent a trojan: say some restricted user creates a script that he's not authorized to execute, but he tricks a system administrator into executing that script. Without intersected roles, his trick will work. But with intersected roles, it probably won't work. Proxy roles, BTW, override the intersected roles. Shane