Guard material writes in ExpGeneratorHelper with UpdatePermission

[ankurjuneja]

Rationale

Tightens permission handling in experiment run creation, with added provenance recording test coverage.

Related Pull Requests

• https://github.com/LabKey/premiumModules/pull/744

Changes

[labkey-jeckels]

Also see the calls to addProvenance, addProvenanceInputs, and addProvenanceOutputs around line 463. Should they get read checked too?

[labkey-jeckels]

Parallel finding probably worth addressing at the same time:

Issue: handleMaterial — the globally-resolving lookup that makes this bug possible — is also called from handleRun for output materials, which flow into saveSimpleExperimentRun. That method does outputMaterial.setSourceApplication(protApp2); outputMaterial.setRun(run); Table.update(...) with no permission check and no isOperationPermitted check anywhere in its body.

Why it matters: The experiment-saveBatch / assay-save APIs reach the identical lineage rewrite on an arbitrary cross-container material through a different entry point. Fixing only the ExpGeneratorHelper write site closes the provenance door while leaving the wider one open, so the security goal in the PR title isn't actually met system-wide. (Pre-existing, not introduced here — but it is the same defect class and shares the same root cause.)
Suggestion: Either push the guard down into handleMaterial (which already knows the resolved material and the ViewContext user) so every caller inherits it, or extract the assertCanEditLineage helper somewhere shared and call it from saveSimpleExperimentRun before the Table.update. If that's deliberately out of scope for this PR, file a follow-up issue and say so in the description.

[labkey-jeckels]

Similar concerns on these inputs, which can come from ProvenanceController.StopRecordingAction