Everything

php

Exposing the linux namespaces API via pcntl_*

php.internals

Pedro Magalhães

7 years ago

Hi internals,

Linux namespaces have been around for a long time and in recent years their
usage has increased dramatically with the popularization of containers.
Modern browsers also make use of them to sandbox certain processes and so
on. To quote an introduction to the subject:

The purpose of each namespace is to wrap a particular global system
resource in an abstraction that makes it appear to the processes within the
namespace that they have their own isolated instance of the global
resource. One of the overall goals of namespaces is to support the
implementation of containers, a tool for lightweight virtualization (as
well as other purposes) that provides a group of processes with the
illusion that they are the only processes on the system.
- from https://lwn.net/Articles/531114/

I think it can be useful for a language to expose this functionality to the
users for that kind of purpose (ie. run a security sensitive task in
isolation, simulate certain conditions like no network access, etc..). For
that end, I've put forward https://github.com/php/php-src/pull/3760 which
provides an implementation of `pcntl_unshare(int $flags): bool`. And I'm
looking for some feedback if anyone would oppose the introduction of this
function (and probably `setns` next).

Regards,
Pedro

Rowan Collins

7 years ago

On 23/01/2019 21:15, Pedro Magalhães wrote:

> I think it can be useful for a language to expose this functionality to the
> users for that kind of purpose (ie. run a security sensitive task in
> isolation, simulate certain conditions like no network access, etc..). For
> that end, I've put forward https://github.com/php/php-src/pull/3760 which
> provides an implementation of `pcntl_unshare(int $flags): bool`. And I'm
> looking for some feedback if anyone would oppose the introduction of this
> function (and probably `setns` next).

Could you give an example of how this would work in the context of a PHP
process? Would it only make sense in a CLI context, when performing some
kind of system task?

I'm struggling to think how you'd use it in a task that would be suited
to PHP, but that's probably just lack of imagination on my part.

Regards,

--
Rowan Collins
[IMSoP]

Pedro Magalhães

7 years ago

On Wed, Jan 23, 2019 at 10:05 PM Rowan Collins <rowan.collins@gmail.com>
wrote:

> On 23/01/2019 21:15, Pedro Magalhães wrote:
> > I think it can be useful for a language to expose this functionality to
> the
> > users for that kind of purpose (ie. run a security sensitive task in
> > isolation, simulate certain conditions like no network access, etc..).
> For
> > that end, I've put forward https://github.com/php/php-src/pull/3760
> which
> > provides an implementation of `pcntl_unshare(int $flags): bool`. And I'm
> > looking for some feedback if anyone would oppose the introduction of this
> > function (and probably `setns` next).
> Could you give an example of how this would work in the context of a PHP
> process? Would it only make sense in a CLI context, when performing some
> kind of system task?
>

Yes, I agree it makes most sense in a CLI context. Some examples I've
thought of:
- For testing frameworks it may be useful to have CLONE_NEWNET as that
should guarantee that a test is executed without any network access;
- For some processing tasks where you may want to mount a remote drive you
can use CLONE_NEWNS to ensure that the mount doesn't affect the host;
- If you are running a daemon controlling multiple child processes you
could issue a `pcntl_unshare(CLONE_NEWPID)` before launching each one of
them so that they can't refer to each other.
- Using all the flags available together with a `chroot` would already give
you a sufficiently isolated environment where you can run some service you
don't want installed on the host.

As for setns, it would allow you to join all the namespaces of a given
process. So your PHP process can join other processes you have unshared
before (or a Docker container for that matter).

Regards,
Pedro