# Swish sandboxing thread\_create build-in predicate **URL:** \ **Category:** Help!\ **Tags:** nice-to-know\ **Created:** [October 21, 2019, 8:57pm UTC](https://swi-prolog.discourse.group/t/swish-sandboxing-thread-create-build-in-predicate/1413 "2019-10-21T20:57:44Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![grossdan](https://yyz2.discourse-cdn.com/free1/user_avatar/swi-prolog.discourse.group/grossdan/32/23_2.png) [@grossdan](https://swi-prolog.discourse.group/u/grossdan)\ **Post date:** [October 21, 2019, 8:57pm UTC](https://swi-prolog.discourse.group/t/swish-sandboxing-thread-create-build-in-predicate/1413/1 "2019-10-21T20:57:44Z")
Hello, Trying to run a predicate in swish that (eventually) calls thread\_create/3 is not allowed. This is a built-in predicate. Trying to declare sandbox:safe\_primitive(thread\_create/3). doesn’t seem to work. Is there a way to allow thread\_create built-in predicates in swish … thank you, Dan ---
**Author:** ![pmoura](https://yyz2.discourse-cdn.com/free1/user_avatar/swi-prolog.discourse.group/pmoura/32/11_2.png) [@pmoura](https://swi-prolog.discourse.group/u/pmoura)\ **Post date:** [October 21, 2019, 9:13pm UTC](https://swi-prolog.discourse.group/t/swish-sandboxing-thread-create-build-in-predicate/1413/2 "2019-10-21T21:13:01Z")
The `thread_create/3` predicate is a meta-predicate. There’s a specific directive for declaring meta-predicated as safe. Try: ```prolog :- multifile sandbox:safe_meta_predicate/1. sandbox:safe_meta_predicate(thread_create/3). ``` ---
**Author:** ![grossdan](https://yyz2.discourse-cdn.com/free1/user_avatar/swi-prolog.discourse.group/grossdan/32/23_2.png) [@grossdan](https://swi-prolog.discourse.group/u/grossdan)\ **Post date:** [October 21, 2019, 9:31pm UTC](https://swi-prolog.discourse.group/t/swish-sandboxing-thread-create-build-in-predicate/1413/3 "2019-10-21T21:31:16Z")
thanks. Unfortunately, it doesn’t seem to work – at least in my installation: No permission to call sandboxed `thread\_create(\_1334,\_1336,\_1338)’ ---
**Author:** ![grossdan](https://yyz2.discourse-cdn.com/free1/user_avatar/swi-prolog.discourse.group/grossdan/32/23_2.png) [@grossdan](https://swi-prolog.discourse.group/u/grossdan)\ **Post date:** [October 22, 2019, 3:46am UTC](https://swi-prolog.discourse.group/t/swish-sandboxing-thread-create-build-in-predicate/1413/4 "2019-10-22T03:46:34Z")
Hi Paolo, It looks like thread\_create/2 is a meta predicate, but thread\_create is a built-in predicate. [https://www.swi-prolog.org/pldoc/doc\_for?object=thread\_create/2](https://www.swi-prolog.org/pldoc/doc_for?object=thread_create/2) There is no link to a module including thread\_create/3, only to thread\_create/2. Dan ---
**Author:** ![pmoura](https://yyz2.discourse-cdn.com/free1/user_avatar/swi-prolog.discourse.group/pmoura/32/11_2.png) [@pmoura](https://swi-prolog.discourse.group/u/pmoura)\ **Post date:** [October 22, 2019, 8:44am UTC](https://swi-prolog.discourse.group/t/swish-sandboxing-thread-create-build-in-predicate/1413/5 "2019-10-22T08:44:17Z")
It’s Paulo, not Paolo. Note that a built-in predicate can also be a meta-predicate: ```prolog ?- predicate_property(thread_create(_,_,_), Property). Property = visible ; Property = built_in ; Property = foreign ; Property = static ; Property = imported_from(system) ; Property = transparent ; Property = (meta_predicate thread_create(0, ?, +)) ; Property = nodebug ; Property = iso ; Property = defined ; false. ``` ---
**Author:** ![grossdan](https://yyz2.discourse-cdn.com/free1/user_avatar/swi-prolog.discourse.group/grossdan/32/23_2.png) [@grossdan](https://swi-prolog.discourse.group/u/grossdan)\ **Post date:** [October 22, 2019, 8:58am UTC](https://swi-prolog.discourse.group/t/swish-sandboxing-thread-create-build-in-predicate/1413/6 "2019-10-22T08:58:30Z")
> It’s Paulo, not Paolo. My apology – i keep getting confused in particular later at night 🙂 I think, while its indeed a meta predicate, perhaps built-in predicates are treated differently when it comes to sandboxing. At least, i tried your suggestion and SWISH raised the same sandbox error. hmm, perhaps i need to prefix it with “system:” Dan ---
**Author:** ![jan](https://yyz2.discourse-cdn.com/free1/user_avatar/swi-prolog.discourse.group/jan/32/4_2.png) [@jan](https://swi-prolog.discourse.group/u/jan)\ **Post date:** [October 23, 2019, 11:38am UTC](https://swi-prolog.discourse.group/t/swish-sandboxing-thread-create-build-in-predicate/1413/7 "2019-10-23T11:38:54Z")
Most likely. Only declared `iso` predicates need no prefix as it is not allowed to redefine them in modules. Still, you probably do not want thread\_create/3 to be allowed in a sandbox. Properly declared it should remain safe, but does escape the resource limitations imposed by sandboxing. In other words, if you allow for thread\_create/3, anyone can request unlimited resources from the server and take it down. ---
**Author:** ![grossdan](https://yyz2.discourse-cdn.com/free1/user_avatar/swi-prolog.discourse.group/grossdan/32/23_2.png) [@grossdan](https://swi-prolog.discourse.group/u/grossdan)\ **Post date:** [October 23, 2019, 3:45pm UTC](https://swi-prolog.discourse.group/t/swish-sandboxing-thread-create-build-in-predicate/1413/8 "2019-10-23T15:45:03Z")
Hi Jan, Thank you. My impression from the sandbox messages I got was that declaring a higher-level predicate as safe isn’t enough for swish; somehow there is a search all the way down to call chain to basic predicates that must be declared as safe as well. Hence, i wanted to declare lower level websocket predicates as safe as well. I guess, this is not the case I do now recall that one can wrap potentially unsafe predicates in higher level ones and make tests to ensure no misuse. I’ll try this again … Dan