feat: add plugin directory trust guard to harden shared plugin caches

[aknownuser]

Summary

Nextflow loads and executes plugin code from the local plugin cache ($id-$version) without re-verifying its origin when the directory already exists — PluginUpdater.load0() short-circuits the download (and therefore the sha512sum/CompoundVerifier path) whenever the cached directory is present, and PluginsFacade.isAllowed() only matches plugin IDs, not content.

On a shared, writable plugin cache (NXF_PLUGINS_DIR or $NXF_HOME/plugins), a lower-trust local user can pre-populate an official pinned plugin coordinate (e.g. nf-amazon@3.10.0) with attacker-controlled code that then runs inside a victim's Nextflow process.

The plugin cache is expected to be a per-user, private trust boundary (default $HOME/.nextflow/plugins). This PR adds a defense-in-depth guard that verifies a plugin directory is trusted before loading it, addressing the exact precondition of the issue — write access to a trusted cache — with no network calls, no checksums, and no persisted state (works offline).

Changes and Reasoning

New PluginSecurity helper (modules/nf-commons/.../plugin/PluginSecurity.groovy)
A directory is considered trusted only when it is owned by the current user (or root) and not writable by group or others. This accepts the two legitimate deployment shapes — a private user cache (e.g. 0700) and an admin-managed read-only shared cache (e.g. root:root 0755) — while rejecting an attacker-owned directory or a group/world-writable cache.

The both-conditions check matters: a permissions-only check would miss the reported scenario, where the poisoned directory was attacker:attacker 755 (not group/other-writable) — ownership is what made it dangerous.

Call sites

• PluginsFacade.init(...) — guards the plugins root at setup (both init overloads), so startup-loaded plugins are covered.
• PluginUpdater.load0() — guards each $id-$version directory immediately before loadPluginFromPath, covering cache reuse and the attacker-owned-subdir case.

New env var NXF_PLUGINS_STRICT_MODE (warn | strict | off)

• warn (default) — logs a warning and continues (zero breakage for existing setups).
• strict — aborts the run with AbortOperationException.
• off — disables the check.

The guard is a no-op on filesystems without POSIX permissions and in dev mode (where plugins load from the source tree, not the cache).

Compatibility / rollout
Default warn means no existing deployment breaks; the default $HOME/.nextflow/plugins (user-owned) is silent. strict is opt-in now; a future stable release can promote the default.

Testing

New PluginSecurityTest (16 cases) and existing plugin tests pass:

• ✅ private 0700 / read-only 0755 → accepted in all modes
• ✅ group/world-writable → warns in warn, throws in strict
• ✅ off mode → never throws
• ✅ null dir / non-POSIX FS → no-op
• ✅ env-var mode resolution (warn default, strict, off)
• ✅ :nf-commons:test full suite — no regression in PluginsFacadeTest / PluginUpdaterTest

End-to-end (dev launcher, NXF_PLUGINS_MODE=prod):

Scenario	Result
strict + 0777 cache	Aborts — workflow does not run
warn + 0777 cache	Warns, workflow proceeds
strict + private 0700 cache	Silent, workflow proceeds

Documentation

• docs/reference/env-vars.mdx — new NXF_PLUGINS_STRICT_MODE entry.
• docs/plugins/using-plugins.mdx — security note in the Caching section (keep the cache private; supported shared pattern is admin-owned read-only).

[netlify]

✅ Deploy Preview for nextflow-docs ready!

Name	Link
🔨 Latest commit	54b91cb
🔍 Latest deploy log	https://app.netlify.com/projects/nextflow-docs/deploys/6a549afe680d6c0008f46747
😎 Deploy Preview	https://deploy-preview-7308--nextflow-docs.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[pditommaso]

The trust-guard's intent is sound and the warn/strict/off plumbing is clean. My concern is the trust predicate itself: it produces false positives in the exact deployment shapes Nextflow is most used in — spurious warnings on every run in the default warn mode, and aborted runs under NXF_PLUGINS_STRICT_MODE=strict. Requesting changes to tighten the predicate, plus a note on a stronger long-term direction.

Blocking — false positives

1. Group-writable check breaks the umask-002 default — PluginSecurity.isUntrusted (PluginSecurity.groovy:94). On stock Ubuntu/Debian/RHEL/Fedora regular-user sessions (umask 002, user-private-group), FilesEx.mkdirs(root) creates ~/.nextflow/plugins as rwxrwxr-x. The guard flags the directory Nextflow just created itself — every run/config/info/log/clean, and every freshly-downloaded plugin dir (PluginUpdater.groovy:406). A dir the user owns is theirs to make group-writable; the threat is a foreign writer.

2. Owner compared by name, not UID — PluginSecurity.groovy:126. When the running UID has no /etc/passwd entry (containers, OpenShift, K8s, arbitrary-UID HPC — very common for Nextflow), System.getProperty('user.name') returns ? while attrs.owner().name resolves to the numeric UID string. Mismatch → the user's own private cache is flagged. Same issue under NFS/LDAP/AD name resolution.

3. Root running against a user-owned cache — PluginSecurity.groovy:95. sudo nextflow … with the user's own 0700 cache: me = root, owner = alice, so alice != me && alice != 'root' → flagged.

4. Only literal root is exempted, but the javadoc promises admin-managed shared caches — PluginSecurity.groovy:95. A read-only shared cache owned by a service account (e.g. nextflow:nextflow 0755) is rejected for every non-admin user. Under site-wide strict, every nextflow run aborts with "refusing to load plugins" — the exact deployment the class doc says is supported.

5. Per-plugin invocation floods duplicate warnings — PluginUpdater.groovy:406. checkTrustedDir runs once per plugin/dependency in load0, so one underlying condition emits N identical warnings per run, and getMode() re-reads the env and re-emits the "Invalid NXF_PLUGINS_STRICT_MODE" warning N times too.

Suggested fixes (cheap, keep it offline-safe)

• Compare owner by UID, not name → fixes #2 and #3.
• Treat group/other-write as untrusted only when the owner isn't you → kills the umask-002 storm (#1).
• Make the trusted-owner set configurable, or trust a read-only dir regardless of owner → #4.
• Warn once per run, not per plugin → #5.

Better long-term strategy

Worth noting for direction (not required in this PR): download-time integrity is already covered — the registry serves sha512sum (HttpPluginRepository.groovy:220) and pf4j's CompoundVerifier checks the archive on download. This guard's real job is the post-download cache-poisoning window.

A load-time "checksum vs registry" would defend that window but requires re-fetching a trusted baseline from the registry on every run — which breaks offline/air-gapped use (a documented, supported mode) and makes registry availability a hard runtime dependency.

The genuinely stronger answer to supply-chain integrity is a committed lockfile with pinned plugin hashes, verified offline at load (the go.sum / package-lock.json model): the trusted baseline lives in the pipeline repo under version control, so it survives cache poisoning and registry compromise and silent drift, with no network. That's a separate, ADR-worthy feature — but it's the direction I'd aim for. This directory guard is a fine cheap complement in the meantime, once the false positives above are fixed.

[aknownuser]

Yes the long term strategy you suggested is the ideal situation, an ADR for that would be perfect!

I have addressed the false positives you detected. Let me know if you think this still needs work.

You may have seen that this setup is opt-in, which is made this way to ovoid any breaking change to previous usage of nextflow.

[christopher-hakkaart]

Adding some style alignment suggestions.

[pditommaso]

Sorry for the churn on this one 🙏 — thanks for bearing with the back-and-forth.

Stepping back, my main worry with the ownership/permission approach is noise on shared filesystems. The check flags a directory as untrusted when it's foreign-owned or world-writable — but the standard HPC/CI setup is an admin- or service-account-owned shared cache that every user reads. For every user who isn't that owner, each plugin dir looks "untrusted", so in the default warn mode we'd emit a warning per plugin, on every run — on a perfectly legitimate, read-only cache. That's exactly the population this is meant to help, and it'd train them to ignore the warnings.

So I took a different iteration in #7394: instead of checking who owns the plugin directory, it pins and verifies a hash of the extracted plugin contents (a committed plugins.lock, go.sum-style, opt-in). Because it checks the bytes that actually get executed, one mechanism covers both cache poisoning and supply-chain/registry tampering — and it uses no ownership heuristic, so it's silent on healthy shared caches and only speaks up on a genuine content mismatch.

I think #7394 supersedes this PR, so I'm inclined to close this in its favour — but happy to hear if you see a gap. Really appreciate the work that got us here; it's what surfaced the whole problem.