Safe man page on CentOS

Man page or keyword search:  
man Server   8420 pages
apropos Keyword Search (all sections)
Output format
CentOS logo
[printable version]

Safe(3pm)	       Perl Programmers Reference Guide		     Safe(3pm)

NAME
       Safe - Compile and execute code in restricted compartments

SYNOPSIS
	 use Safe;

	 $compartment = new Safe;

	 $compartment->permit(qw(time sort :browse));

	 $result = $compartment->reval($unsafe_code);

DESCRIPTION
       The Safe extension module allows the creation of compartments in which
       perl code can be evaluated. Each compartment has

       a new namespace
	       The "root" of the namespace (i.e. "main::") is changed to a
	       different package and code evaluated in the compartment cannot
	       refer to variables outside this namespace, even with run-time
	       glob lookups and other tricks.

	       Code which is compiled outside the compartment can choose to
	       place variables into (or share variables with) the compart‐
	       ment's namespace and only that data will be visible to code
	       evaluated in the compartment.

	       By default, the only variables shared with compartments are the
	       "underscore" variables $_ and @_ (and, technically, the less
	       frequently used %_, the _ filehandle and so on). This is
	       because otherwise perl operators which default to $_ will not
	       work and neither will the assignment of arguments to @_ on sub‐
	       routine entry.

       an operator mask
	       Each compartment has an associated "operator mask". Recall that
	       perl code is compiled into an internal format before execution.
	       Evaluating perl code (e.g. via "eval" or "do 'file'") causes
	       the code to be compiled into an internal format and then, pro‐
	       vided there was no error in the compilation, executed.  Code
	       evaluated in a compartment compiles subject to the compart‐
	       ment's operator mask. Attempting to evaluate code in a compart‐
	       ment which contains a masked operator will cause the compila‐
	       tion to fail with an error. The code will not be executed.

	       The default operator mask for a newly created compartment is
	       the ':default' optag.

	       It is important that you read the Opcode(3) module documenta‐
	       tion for more information, especially for detailed definitions
	       of opnames, optags and opsets.

	       Since it is only at the compilation stage that the operator
	       mask applies, controlled access to potentially unsafe opera‐
	       tions can be achieved by having a handle to a wrapper subrou‐
	       tine (written outside the compartment) placed into the compart‐
	       ment. For example,

		   $cpt = new Safe;
		   sub wrapper {
		       # vet arguments and perform potentially unsafe operations
		   }
		   $cpt->share('&wrapper');

WARNING
       The authors make no warranty, implied or otherwise, about the suitabil‐
       ity of this software for safety or security purposes.

       The authors shall not in any case be liable for special, incidental,
       consequential, indirect or other similar damages arising from the use
       of this software.

       Your mileage will vary. If in any doubt do not use it.

       RECENT CHANGES

       The interface to the Safe module has changed quite dramatically since
       version 1 (as supplied with Perl5.002). Study these pages carefully if
       you have code written to use Safe version 1 because you will need to
       makes changes.

       Methods in class Safe

       To create a new compartment, use

	   $cpt = new Safe;

       Optional argument is (NAMESPACE), where NAMESPACE is the root namespace
       to use for the compartment (defaults to "Safe::Root0", incremented for
       each new compartment).

       Note that version 1.00 of the Safe module supported a second optional
       parameter, MASK.	 That functionality has been withdrawn pending deeper
       consideration. Use the permit and deny methods described below.

       The following methods can then be used on the compartment object
       returned by the above constructor. The object argument is implicit in
       each case.

       permit (OP, ...)
	       Permit the listed operators to be used when compiling code in
	       the compartment (in addition to any operators already permit‐
	       ted).

	       You can list opcodes by names, or use a tag name; see "Prede‐
	       fined Opcode Tags" in Opcode.

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

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

       deny_only (OP, ...)
	       Deny only the listed operators from being used when compiling
	       code in the compartment (all other operators will be permit‐
	       ted).

       trap (OP, ...)
       untrap (OP, ...)
	       The trap and untrap methods are synonyms for deny and permit
	       respectfully.

       share (NAME, ...)
	       This shares the variable(s) in the argument list with the com‐
	       partment.  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).

       share_from (PACKAGE, ARRAYREF)
	       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 ref‐
	       erence.

		   $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' ]);

       varglob (VARNAME)

       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.

       reval (STRING)
	       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 refer‐
	       ence, those code references are wrapped to be themselves exe‐
	       cuted 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 com‐
	       partment, or by code called from code executing in a compart‐
	       ment, 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.

       rdo (FILENAME)
	       This evaluates the contents of file FILENAME inside the com‐
	       partment.  See above documentation on the reval method for fur‐
	       ther details.

       root (NAMESPACE)
	       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 names‐
	       pace. That functionality has been withdrawn pending deeper con‐
	       sideration.

       mask (MASK)
	       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).

       wrap_code_ref (CODEREF)

       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 <http://rt.perl.org/rt3//Public/Bug/Dis‐
       play.html?id=60374> for much more detail.)

       wrap_code_refs_within (...)

       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.

RISKS
       This section is just an outline of some of the things code in a com‐
       partment might do (intentionally or unintentionally) which can have an
       effect outside the compartment.

	       Memory  Consuming all (or nearly all) available memory.

	       CPU     Causing infinite loops etc.

	       Snooping
		       Copying private information out of your system. Even
		       something as simple as your user name is of value to
		       others. Much useful information could be gleaned from
		       your environment variables for example.

	       Signals Causing signals (especially SIGFPE and SIGALARM) to
		       affect your process.

		       Setting up a signal handler will need to be carefully
		       considered and controlled.  What mask is in effect when
		       a signal handler gets called?  If a user can get an
		       imported function to get an exception and call the
		       user's signal handler, does that user's restricted mask
		       get re-instated before the handler is called?  Does an
		       imported handler get called with its original mask or
		       the user's one?

	       State Changes
		       Ops such as chdir obviously effect the process as a
		       whole and not just the code in the compartment. Ops
		       such as rand and srand have a similar but more subtle
		       effect.

AUTHOR
       Originally designed and implemented by Malcolm Beattie.

       Reworked to use the Opcode module and other changes added by Tim Bunce.

       Currently maintained by the Perl 5 Porters, <perl5-porters@perl.org>.

perl v5.8.8			  2001-09-21			     Safe(3pm)
[top]

List of man pages available for CentOS

Copyright (c) for man pages and the logo by the respective OS vendor.

For those who want to learn more, the polarhome community provides shell access and support.

[legal] [privacy] [GNU] [policy] [cookies] [netiquette] [sponsors] [FAQ]
Tweet
Polarhome, production since 1999.
Member of Polarhome portal.
Based on Fawad Halim's script.
....................................................................
Vote for polarhome
Free Shell Accounts :: the biggest list on the net