Code which is compiled outside the compartment can choose to place variables into (or share variables with) the compartment'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 subroutine entry.
By default, the operator mask for a newly created compartment masks out all operations which give ``access to the system'' in some sense. This includes masking off operators such as system , open , chown , and shmget but does not mask off operators such as print , sysread and <HANDL>. Those file operators are allowed since for the code in the compartment to have access to a filehandle, the code outside the compartment must have explicitly placed the filehandle variable inside the compartment.
(Note: the definition of the default ops is not yet finalised.)
Since it is only at the compilation stage that the operator mask applies, controlled access to potentially unsafe operations can be achieved by having a handle to a wrapper subroutine (written outside the compartment) placed into the compartment. For example,
The canonical list of operator names is the contents of the array op_name defined and initialised in file opcode.h of the Perl source distribution (and installed into the perl library).
Each operator has both a terse name and a more verbose or recognisable descriptive name. The opdesc function can be used to return a list of descriptions for a list of operators.
Many of the functions and methods listed below take a lists of operators as parameters. Operator lists can be made up of several types of elements. Each element can be one of
The ops_to_opset and opset_to_ops functions can be used to convert from a list of operators to an opset (and vice versa).
Wherever a list of operators can be given you can use one or more opsets.
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.
Each VARNAME must be the name of a variable with a 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).
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 operation...''.
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.
This behaviour differs from the beta distribution of the Safe extension where earlier versions of perl made it hard to mimic the return behaviour of the eval() command and the context was always scalar.
Some points to note:
If the entereval/leaveeval ops are permitted then the code can use them 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 bar 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 '$baz = 1' then, normally, $bar::foo will be set to 1. If foo() is called from the compartment (by whatever means) then instead of setting $bar::foo, the eval will actually set $Root::bar::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.
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.
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).
This is useful if you want a compartment to make use of the namespace protection features but do not want the default restrictive mask.
:. The optag name used must not be defined already
(define_optag will croak if it is already defined). Optag names are
global to the perl process and optag definitions cannot be altered or
deleted once defined.
It is strongly recommended that applications using Safe should use a leading capital letter on their tag names since lowercase names are reserved for use by the Safe module. If using Safe within a module you should prefix your tags names with the name of your module to ensure uniqueness.
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?
Note that despite the existance of this optag a memory resource attack may still be possible using only :base_core ops.
Disabling these ops is a very heavy handed way to attempt to prevent a memory resource attack. It's probable that a specific memory limit mechanism will be added to perl in the near future.
These ops are not included in :base_core because they have an effect beyond the scope of the compartment.
SystemV Interprocess Communications:
Optags and other changes added by Tim Bunce <Tim.Bunce@ig.co.uk>.