- Created by Unknown User (sarah), last modified by Unknown User (sarah.kiniry) on Jun 13, 2016
Poor implementations of this system may cause
root-privilege vulnerabilities and compromised servers. Read the Security requirements section of this document before you use this system.
To run a function with escalated privileges, call a function through the
Call method or use the pluggable wrapper. The system manages privilege escalation, and ensures that the user can only run the permitted code.
- This set of documents applies to cPanel & WHM version 11.38 and later.
- cPanel, Inc. introduced the
Callmethod for Perl admin modules in cPanel & WHM version 54 in order to simplify construction of modules. We recommend that you write admin modules with this method when possible. For earlier versions and other programming languages, use the Standard Method.
- For information about the legacy method of API privilege escalation (for cPanel & WHM version 11.36 and earlier), read our Legacy API Privilege Escalation documentation.
cPanel, Inc. introduced this functionality in cPanel & WHM version 54 for admin modules in Perl.
As of cPanel & WHM version 54, cPanel recommends that you develop admin modules as subclasses of the cPanel-provided
Cpanel::AdminBin::Script::Call base class. This class, and the
Cpanel::AdminBin::Call module that accompanies it, contain privilege escalation logic so that admin modules are simpler to write and call.
To make a module “TheModule” in the namespace “TheNameSpace” perform the following steps:
- Create the
Run the following command to create the configuration file:
Create your new module in the
- Set that file to be executable with the following command:
chmod 0700 /usr/local/cpanel/bin/admin/TheNamespace/TheModule
The following example admin module uses the
run(OPTS) runs the script after it checks whether the first element in the value of the
@ARGV array is
--bincheck exists in the
@ARGV array, the system prints the
BinCheck ok message with a trailing newline and the process performs an
This is normally how Call-type admin modules should invoke themselves when run from a script.
OPTS is an optional list of arguments that can include:
alarm— An integer that represents a timeout value for the script. This option defaults to 350 seconds.
new(OPTS) is identical to
run(), but it does not check if the first element in the value of the
@ARGV array is
--bincheck. This will help you test your module.
To call the
DO_GOOD function from unprivileged code, you would use the following:
The above example passes two parameters,
'first arg' and
['second arg'], to the
DO_GOOD method in the admin module. This particular example returns one value, but you may also return a list. Input parameters and return values may be scalars, array references, or hash references. This structure does not support scalar references, references that use the
bless() function, and self-referential data structures as inputs or outputs.
The code calls the admin function with the same context (void, scalar, or list) as the
Cpanel::AdminBin::Call::call() method itself. (The system handles “mismatched” returns — for example, returning an array in scalar context — as Perl handles them.) The admin module traps exceptions, and then re-throws them without a stack trace in the code that calls them.
For a full example, read our Guide to API Privilege Escalation - Call Your Application documentation.
$self parameter in the example contains a reference to the instance of your admin module and class. Your class will inherit several useful methods such as
get_caller_username() from the
For more information, read our Guide to API Privilege Escalation - Object Methods documentation.
To use privilege escalation in your custom code, perform the following steps:
- Create the following files:
- Store these files in a new namespace in the
- The namespace and the directory name must be identical.
- Do not create your
AdminBinapplication inside the
Whenever you use this system, do not manipulate files or directories that a user owns as the
root user, or execute any actions on unvalidated input.
You must adhere to the following security practices:
- Only use this system to execute code that must run as the
- Thoroughly validate any input that passes through this system.
- Sanitize the
To sanitize the
admin script's environment, set environment variables to limit the paths from which the script loads libraries.
- This action sanitizes the
@INCarray, and ensures that users cannot load arbitrary libraries.
The following example adds the
/usr/local/cpanel/directory to the environment, and then removes entries that do not match standard Perl library paths: