Userland access to `internalBinding` (at one's own risk)

[bengl]

At Intrinsic, we make use of process.binding('natives') in order to re-evaluate Node.js core modules inside our isolation environment. In order for these modules to work, we need to have the binding layer accessible. This is similar to how the natives module works.

The introduction of internalBinding was of no issue on its own, since we could just use process.binding to replicate its behaviour. However, there are now modules such as string_decoder that now having binding parts that are inacessible to userland. We can't simply require that users run with --expose-internals as our customers aren't always in control of CLI arguments. Also, our product is delivered as a Node.js module, rather than a separate binary, and we'd like to keep it that way.

Note: The natives module is subject to the same issue. Here is a quick example using RunKit.

We do have some workarounds involving re-implementing the exposed APIs, but we find this to be prone to errors and subject to extra maintenance for new versions of Node.js.

What we'd like to do is introduce a way of accessing internalBinding-provided code from userland. I know this seems counterintuitive, given the purpose of internalBinding, so it would make the most sense for it to be provided in C++ only, requiring some native code to actually get access to it. The difficulty in accessing it is an acknowledgement that we're not expecting the same level of support that the normal user-facing API has. (We would expect basically no support for the actual internal bindings, but we wouldn't expect this access to disappear.) We're certainly open to other suggestions, but we'd like a solution that's maintainable and sustainable.

What do folks think?

[devsnek]

i'm very -1 on exposing these bindings, the entire point of adding internalBinding was to prevent userland from accessing them. perhaps we can find another solution. what big picture functionality was process.binding giving you?

cc @addaleax @joyeecheung

[mscdex]

-1 I agree it would be better to focus on actual needs rather than just blanket access to internals.

[bengl]

@devsnek @mscdex Our isolation layer sits at low level in order to better interpose on APIs. We evaluate code from process.binding('natives') (that is, stuff from the lib folder) inside our isolation environment. We provide shimmed versions of low-level functionality (such as process.binding itself) in order to enable these modules, as well as apply our fine-grained policies.

We're already shipping a product that uses process.binding for this purpose, so we're looking for a way to make this continue to work with the move toward internalBinding-only modules.

To reiterate, I'm not suggesting that anything added here would be any more supported than process.binding is today. That is, we'd be totally fine with any breakages of this API between releases (even patch releases).

[devsnek]

why doesn't just replacing process.binding and the public interfaces work? the only way internal bindings are called is via the public interfaces anyway.

[bengl]

@devsnek We interpose at the low level in order to implement our fine-grained policies with less maintenance and performance overhead. Many of our policies are considerably easier to implement at that level due to normalization and the way some parts of the public API interact with others internally. Either performing those normalizations ourselves or re-implementing the interactions that already happen within the lib folder would result in unnecessary performance hits.

[devsnek]

how exactly do you intercept these calls? if you're using stack traces/context tracking then some hooks for things like "on fs read" and "on socket open" might work.

[refack]

As far as I remember the main issue we wanted to prevent was un-audited access to internals by 3rd party modules. That's why the only way to enable access was with a CLI flag. If you could think of a different way to give the process owner exclusive control, I think that is the main blocker.

[devsnek]

There was also the issue of whenever we changed parts of the undocumented api, huge modules with millions of dependents would break and topple the ecosystem.

[bengl]

@devsnek We intercept these calls by construction: we re-evaluate lib folder code inside of our isolation contexts and intercept any function calls coming out of them. These isolation contexts are essential in order to maintain separation between differing sets of policies.

[devsnek]

@bengl without more information on "isolation contexts" and "intercepting any function calls" and all of that i'm not sure how much help i personally can provide. is it possible to provide some more technical detail? (or even better, code)

[refack]

huge modules with millions of dependents would break

Yes, that's what I meant with un-audited. The users of those modules (i.e. those how own the process) were not aware of the risk the module authors were taking on their behalf.

As I see it that's the problem with "at one's own risk", who is one ¯\(ツ)/¯

[refack]

Another idea that comes up once in a while is a drop-in modular stdlib. Write your own stdlib files, place them in a special place and the runtime will pick them up instead of the bundled ones. Again the key here is that only the owner can do that, and is aware of the risks and trade-offs.

[bengl]

Unfortunately I can't show code, since it's not an open source product. That being said, we use isolated JavaScript environments that do not include require or other Node.js things, and then we insert wrapped APIs deliberately, with our policy governing their actions. That's the environment that we evaluate the lib folder code in.

At this point, our (Intrinsic's) options are to either somehow have access to internalBinding or effectively the same functionality, or re-implement the bindings entirely ourselves. Re-implementing it ourselves at best introduces compatibility problems we're not comfortable with and at worst introduces performance hits our customers can't afford.

@refack Unfortunately owner-only solutions aren't really enough for us because we support environments where the people deploying Intrinsic aren't the process owners (e.g. serverless).

I certainly understand the reasoning behind introducing internalBinding, but since we need access to it in userland in order for our product to be performant, maintainable, and have the same feature set as it did before, I'm suggesting the introduction of an API that's more difficult to use than process.binding (C++ is a barrier for a lot of people), and even adding whatever warning messaging is desired in order to discourage people from using it en-masse.

[devsnek]

@bengl is an environment a v8 isolate? a v8 context? something else? the more information we have the better we can help.

if you're using isolates, perhaps a new api on worker threads would work?

new Worker(path, {
  hooks: {
    // names and granularity tbd obviously
    fsOpen: (path) => { return true or false to allow operation },
    fsRead: (path) => {},
    ...
  },
});

we've also got policies in development which might internally need hooks that intrinsic could take advantage of (cc @bmeck on that)