The Perl Toolchain Summit needs more sponsors. If your company depends on Perl, please support this very important event.

NAME

Sys::Linux::Syscall::Execve - A raw execve() wrapper that preserves memory addresses

DESCRIPTION

Due to changes in how exec() works in the upcoming 5.28 to fix [perl #129888] I can no longer expect exec() to preserve the memory address of the arguments provided to it.

Why this weird requirement? It's because I need to preserve that address in order to setup an eBPF program with Seccomp that restricts what can be executed inside a sandbox.

SHOULD I USE THIS

No. Perl's built in exec() is better for every use case that you'll ever have. Not only is it portable, it handles many more edge cases than you can ever expect this to acknowledge even exist.

This is only if you need to restrict the execve() syscall in a Seccomp sandbox. There are no other possible uses for this.

EXPORT_OK

execve

A simple recreation of perl's exec() but using our internal code to execute everything. However it will never invoke a shell automatically. This will pass %ENV to the executed program.

execve_env
    execve_env("/path/to/cmd", [arg1, arg2, arg3, ...], {env_var => value, ...});

Lets you setup a custom environment to be passed to the new program. Useful for sanatizing everything for the new program.

execve_byref
    my $cmd = "/path/to/cmd";
    my $args = [arg1, arg2, arg3, ...];
    my $env = {env_var => value, ...};

    execve_byref(\$cmd, $args, $env);

This is a special interface, passing the command in as a scalar ref helps ensure that the correct string gets passed by pointer to execve() at the final stage. This is necessary to be perfectly sure that the correct value is passed to the syscall.

TODO

Enable getting the address of arguments and environment variables to be passed also, for extra paranoia

SEE ALSO

App::EvalServerAdvanced

AUTHOR

Ryan Voots <simcop@cpan.org>