Manpages - Safe.3perl

Permit the listed operators to be used when compiling code in the compartment (in addition to any operators already permitted).

You can list opcodes by names, or use a tag name; see Predefined Opcode Tags in Opcode.

Permit only the listed operators to be used when compiling code in the compartment (no other operators are permitted).

Deny the listed operators from being used when compiling code in the compartment (other operators may still be permitted).

Deny only the listed operators from being used when compiling code in the compartment (all other operators will be permitted, so you probably don’t want to use this method).

The trap and untrap methods are synonyms for deny and permit respectfully.

This shares the variable(s) in the argument list with the compartment. This is almost identical to exporting variables using the Exporter module.

Each NAME must be the name of a non-lexical variable, typically with the leading type identifier included. A bareword is treated as a function name.

Examples of legal names are ’$foo’ for a scalar, ’@foo’ for an array, ’%foo’ for a hash, ’&foo’ or ’foo’ for a subroutine and ’*foo’ for a glob (i.e. all symbol table entries associated with foo, including scalar, array, hash, sub and filehandle).

Each NAME is assumed to be in the calling package. See share_from for an alternative method (which share uses).

This method is similar to share() but allows you to explicitly name the package that symbols should be shared from. The symbol names (including type characters) are supplied as an array reference.

$safe->share_from(main, [ $foo, %bar, func ]);

Names can include package names, which are relative to the specified PACKAGE. So these two calls have the same effect:

$safe->share_from(Scalar::Util, [ reftype ]); $safe->share_from(main, [ Scalar::Util::reftype ]);

This returns a glob reference for the symbol table entry of VARNAME in the package of the compartment. VARNAME must be the name of a variable without any leading type marker. For example:

${$cpt->varglob(foo)} = “Hello world”;

has the same effect as:

$cpt = new Safe Root; $Root::foo = “Hello world”;

but avoids the need to know $cpt’s package name.

This evaluates STRING as perl code inside the compartment.

The code can only see the compartment’s namespace (as returned by the root method). The compartment’s root package appears to be the main:: package to the code inside the compartment.

Any attempt by the code in STRING to use an operator which is not permitted by the compartment will cause an error (at run-time of the main program but at compile-time for the code in STRING). The error is of the form ’%s’ trapped by operation mask….

If an operation is trapped in this way, then the code in STRING will not be executed. If such a trapped operation occurs or any other compile-time or return error, then $@ is set to the error message, just as with an eval().

If there is no error, then the method returns the value of the last expression evaluated, or a return statement may be used, just as with subroutines and eval(). The context (list or scalar) is determined by the caller as usual.

If the return value of reval() is (or contains) any code reference, those code references are wrapped to be themselves executed always in the compartment. See wrap_code_refs_within.

The formerly undocumented STRICT argument sets strictness: if true ’use strict;’ is used, otherwise it uses ’no strict;’. Note: if STRICT is omitted ’no strict;’ is the default.

Some points to note:

If the entereval op is permitted then the code can use eval … to ’hide’ code which might use denied ops. This is not a major problem since when the code tries to execute the eval it will fail because the opmask is still in effect. However this technique would allow clever, and possibly harmful, code to ’probe’ the boundaries of what is possible.

Any string eval which is executed by code executing in a compartment, or by code called from code executing in a compartment, will be eval’d in the namespace of the compartment. This is potentially a serious problem.

Consider a function foo() in package pkg compiled outside a compartment but shared with it. Assume the compartment has a root package called ’Root’. If foo() contains an eval statement like eval ’$foo = 1’ then, normally, $pkg::foo will be set to 1. If foo() is called from the compartment (by whatever means) then instead of setting $pkg::foo, the eval will actually set $Root::pkg::foo.

This can easily be demonstrated by using a module, such as the Socket module, which uses eval … as part of an AUTOLOAD function. You can ’use’ the module outside the compartment and share an (autoloaded) function with the compartment. If an autoload is triggered by code in the compartment, or by any code anywhere that is called by any means from the compartment, then the eval in the Socket module’s AUTOLOAD function happens in the namespace of the compartment. Any variables created or used by the eval’d code are now under the control of the code in the compartment.

A similar effect applies to all runtime symbol lookups in code called from a compartment but not compiled within it.

This evaluates the contents of file FILENAME inside the compartment. It uses the same rules as perl’s built-in do to locate the file, poossibly using @INC.

See above documentation on the reval method for further details.

This method returns the name of the package that is the root of the compartment’s namespace.

Note that this behaviour differs from version 1.00 of the Safe module where the root module could be used to change the namespace. That functionality has been withdrawn pending deeper consideration.

This is a get-or-set method for the compartment’s operator mask.

With no MASK argument present, it returns the current operator mask of the compartment.

With the MASK argument present, it sets the operator mask for the compartment (equivalent to calling the deny_only method).

Returns a reference to an anonymous subroutine that, when executed, will call CODEREF with the Safe compartment ’in effect’. In other words, with the package namespace adjusted and the opmask enabled.

Note that the opmask doesn’t affect the already compiled code, it only affects any further compilation that the already compiled code may try to perform.

This is particularly useful when applied to code references returned from reval().

(It also provides a kind of workaround for RT#60374: Safe.pm sort {} bug with -Dusethreads. See https://rt.perl.org/rt3//Public/Bug/Display.html?id=60374 for much more detail.)

Wraps any CODE references found within the arguments by replacing each with the result of calling wrap_code_ref on the CODE reference. Any ARRAY or HASH references in the arguments are inspected recursively.

Returns nothing.