Repository navigation
Replies: 2 comments 2 replies
|
Hello @tgxworld, Yes, maybe, though I wonder if complicated changes to blocking are best done in eg. Ruby? We could consider adding block / allow as separate env vars, perhaps: It would make parsing and ordering simpler. |
We did consider this but since we spawn a Landlock child process, it would mean having to maintain a custom C helper or ruby script in order to forward vips operations to. A ruby script is more comfortable for me to maintain but ruby does boot slower compared to vips CLI. On my machine, a ruby script is about ~23ms of startup overhead compared to ~6ms of startup overhead for vips CLI.
Tiny suggestion but perhaps the values can be standardized on the class name like below? |
|
You can use either the classname or the nickname in all block / unblock operations. The nickname is useful since it is part of the supported API and therefore guaranteed to be stable. |
|
I made an enhancement issue: Thanks for the idea! |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Hi,
Similar to the
VIPS_BLOCK_UNTRUSTEDenv, I'm wondering if a similar env can be added to support settingvips_operation_block_setwhen using the vips CLI so that I can specify a custom list of loaders which I would like to allow. In my use case, I'm running a Rails application but intentionally avoid ruby-vips and instead shells out to the vips CLI in a child process within a Landlock sandbox that has resource limits configured. Perhaps something like this with an ordered list can be considered?Thank you for the consideration.
All reactions