I propose a new foreign conjunction, and submit a simple design implementation, for a security feature meant to be applied to '".' '0!:' , and other code executing or top level functions that might call untrusted code. The basic conjunction parameters for picking arbitrary name 9!:55 :
u 9!:55 n : n is a boxed list of literals containing the blacklist of foreigns and built-in definitions. When u y is run, any call to a blacklisted name results in a 'security violation' error. After u y completes, the blacklist is removed. The simplest implementation if you believe this deserves little effort, is to set all pointers to functions in the blacklist to a temporary 'return error' function, and restore them after u y completes, and to raise an error if a nested 13!55 call is attempted. The next level of sophistication might allow for nested calls, with inner calls able to add to the blacklist but not subtract. One feature that makes implementation trickier, and I'm not positive is strictly necessary, but I think most people would appreciate would be: m 9!:55 n : n is same, but m is a literal verb to execute that may contain calls that are blacklisted in n. One implementation might be to allow the first call to a blocked verb and disallow all others. The reason I think this may not be necessary is that if you are executing untrusted code with 'do', then you probably have no need to blacklist 'do' since everything they could not do without do, they still can't do with 'do'. One feature I think would be very useful is to be able to blacklist noun access such as MYPASSWORD, but this maybe better implemented as whitelisting one locale. Since one of the blacklisted functions may very well be '=:', and I already mentioned whitelisting exceptions, a further enhancement might be using n as a 2 level boxed list with the first item still the blacklist, but later items could form the basis for a small dsl to grant exceptions such as allowing '* _private_ =: *'. I picture a 3 item 2 level boxed list. The 2nd box contains a whitelist of locales where Names can be read, and the 3rd box could be whitelisted patterns for '=:'. I doubt that whitelisting patterns for other functions is worth implementing, but I could be wrong. I'd be happy to contribute typical blacklists. APPLICATIONS: running the JHS ijx main loop (as u) under the context of such an adverb running user socket servers that allow more user commands/computations than can be easily white listed. DSLs created subtractively with up to the full power of J. While there is a slightly similar 9!:24, that design does too much at the J engine level compromising flexibility. Incidentally, 16!:n is undocumented. What do those do? Enthusiasm or criticism welcome, ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
