Preloading support for php-vips in the future?

[futureweb]

Hi!

First of all, thanks for the awesome work on php-vips. I would really like to use php-vips 2 on production systems, but the need to enable FFI globally (due to missing preloading support) is a big concern from a security perspective.

I know that if someone already has PHP access, there are already bigger issues, but I’d still like to minimize risks as much as possible -especially on production environments.

Is there any plan to support FFI preloading in the near future, or any ideas on how this limitation might be solved going forward?

Thanks a lot!

[jcupitt]

Hi @futureweb,

We'd love to support it, someone just needs to volunteer to do the work. I don't think it would be difficult, but it would need a little expertise in php server config and testing (which I don't have).

[wadakatu]

It turns out this already works, with no changes to php-vips — you just have to preload php-vips itself.

Under ffi.enable=preload, PHP permits an FFI call when the calling function was compiled during opcache.preload. See zend_ffi_validate_api_restriction() in ext/ffi/ffi.c (lines 2996-3011 in php-8.4.24, 2842-2856 in php-7.4.33). Note it also short-circuits on FFI_G(is_cli), which ZEND_MINIT_FUNCTION(ffi) sets from strcmp(sapi_module.name, "cli") == 0 — so the cli SAPI is exempt entirely and testing on the command line tells you nothing.

php-vips calls \FFI::cdef() from its own classes, so putting vendor/jcupitt/vips/src into your preload script is enough. No .h file, no FFI::scope, no ffi.preload.

On 2.6.1:

// preload.php
require __DIR__ . '/vendor/autoload.php';
interface_exists(\Psr\Log\LoggerInterface::class);
trait_exists(\Psr\Log\LoggerTrait::class);
foreach (glob(__DIR__ . '/vendor/jcupitt/vips/src/*.php') as $file) {
    opcache_compile_file($file);
}

ffi.enable = preload
opcache.preload = /path/to/preload.php

I checked this on php 7.4.33 with libvips 8.10.5, and on php 8.4.24 with libvips 8.16.1, served over php -S so the SAPI is cli-server and the restriction really applies: thumbnails, file and buffer loads, metadata, signalConnect progress, SourceCustom/TargetCustom streaming. Output is byte-identical to the same code under ffi.enable=true. Dropping just the opcache.preload line from that setup gives FFI\Exception: FFI API is restricted by "ffi.enable" configuration directive, so the restriction really was in force.

Two caveats.

Preload all of src. PHP checks per calling function, so preloading only some files starts up fine and then throws on first use — with only FFI.php preloaded, \FFI::cdef() succeeds but \FFI::string() in Utils.php throws the restriction error.

And master is stricter than 2.6.1: #287 made FFI::init() reject ffi.enable=preload outright, so this stops working on the next release. With the preload script above you get Jcupitt\Vips\Exception: ffi.enable set to 'preload', not 'true' on first use; if your preload script also warms php-vips up, it is a fatal error at startup and the process will not boot.

#291 fixes that, and adds an FFI::preload() so the loop above becomes one call.

Edited to correct the libvips version I tested under php 7.4, to pin the ffi.c line numbers to specific php releases, and to say more precisely where master throws.