Swish sandboxing thread_create build-in predicate


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,


The thread_create/3 predicate is a meta-predicate. There’s a specific directive for declaring meta-predicated as safe. Try:

:- multifile sandbox:safe_meta_predicate/1.
1 Like


Unfortunately, it doesn’t seem to work – at least in my installation:

No permission to call sandboxed `thread_create(_1334,_1336,_1338)’

Hi Paolo,

It looks like thread_create/2 is a meta predicate, but thread_create is a built-in predicate.


There is no link to a module including thread_create/3, only to thread_create/2.


It’s Paulo, not Paolo.

Note that a built-in predicate can also be a meta-predicate:

?- 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 ;

It’s Paulo, not Paolo.

My apology – i keep getting confused in particular later at night :slight_smile:

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:”


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.

1 Like

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 …