user
Does the language implementation allow for a "safer mode" of execution? Usually termed **Safe mode**, a more realistic view is probably **Safer mode** or **restricted mode**. It is one thing to place restrictions on execution, and another thing entirely to allow execution of scripts from untrusted sources and assume nothing untoward will happen.

Along with a simple yes/no answer, describe what features are restricted when running in safe mode.
assistant
(formerly Perl 6)

*Mostly a cut-n-paste from the Untrusted environment task.*

Raku doesn't really provide a high security mode for untrusted environments. By default, Raku is sort of a walled garden. It is difficult to access memory directly, especially in locations not controlled by the Raku interpreter, so unauthorized memory access is unlikely to be a threat with default Raku commands and capabilities.

It is possible (and quite easy) to run Raku with a restricted setting which will disable many IO commands that can be used to access or modify things outside of the Raku interpreter. However, a determined bad actor could theoretically work around the restrictions, especially if the nativecall interface is available. The nativecall interface allows directly calling in to and executing code from C libraries so anything possible in C is now possible in Raku. This is great for all of the power it provides, but along with that comes the responsibility and inherent security risk. The same issue arises with unrestricted loading of modules. If modules can be loaded, especially from arbitrary locations, then any and all restriction imposed by the setting can be worked around.

The restricted setting is modifiable, but by default places restrictions on or completely disables the following things:

User Subroutines (disabled)

:   * sub chmod() *modify filesystem permissions*
    * sub copy() *copy a file*
    * sub link() *create a link to a file*
    * sub mkdir() *make a filesystem directory*
    * sub open() *open a filesystem location / file*
    * sub pipe() *open a pipe*
    * sub QX() *execute arbitrary code*
    * sub rename() *rename a file*
    * sub rmdir() *remove a directory*
    * sub run() *run arbitrary code*
    * sub shell() *execute code in a shell*
    * sub socket() *open a socket*
    * sub spurt() *write a file*
    * sub symlink() *create a symbolic link to a location*
    * sub unlink() *delete a file*

Internal Subroutines (disabled)

:   * sub CHANGE-DIRECTORY *change directory*
    * sub CHMOD-PATH *change permissions*
    * sub COPY-FILE *copy a file*
    * sub MAKE-DIR *make a directory*
    * sub REMOVE-DIR *remove a directory*
    * sub RENAME-PATH *rename a directory*
    * sub SYMLINK-PATH *create a symbolic link*
    * sub UNLINK-PATH *delete a file*

Classes (disabled)

:   * class IO::CatHandle *streaming file handle*
    * class IO::Handle *file handle*
    * class IO::Path *filesystem path*
    * class IO::Pipe *OS pipe*
    * class IO::Socket *OS socket*
    * class IO::Socket::INET *Network socket*
    * class NativeCall *Nativecall interface to foreign code (C mostly)*
    * class Proc *OS Process*
    * class Proc::Async *Asynchronous OS Process*

Method Mixins / Roles (locked down so can't be overridden)

:   * method FALLBACK() *handle unknown method calls*
    * method new() *create a new instance*
    * method gist() *display method*

Really, if you want to lock down a Raku instance so it is "safe" for unauthenticated, untrusted, general access, you are better off running it in some kind of locked down virtual machine or sandbox managed by the operating system rather than trying to build an ad hoc "safe" environment.