Lint Batch 4: SEC014 external-role writes, CONV009 reads maxObjects

[MendixMau]

#268: SEC014, an external role that can write state, audit or ownership members

Problem. A partner, customer or portal role granted create, read *, write * … where [owner = CurrentUser] passes every stock rule:

• CONV006 checks only create and delete.
• CONV007 checks only for a missing XPath.
• The SEC00x rules check only settings and PII reads.

Yet that role can set its own record's Status through the client API, skipping the approval microflow. In the field this showed up only as CONV006 +4, which was re-baselined. A manual review found it five days later.

Fix. New rule lint-rules/sec014_external_role_write.star: warning severity, in the security tier (the SEC* default in lint-gate.sh).

• Configuration. The project names its external roles in .claude/lint-config.yaml: rules: SEC014: options: external_roles: "A, B". A name can be a user role or a module role, qualified or bare.
• What it flags. One finding per entity × role when the role can write:
  • every attribute (write *);
  • an Enumeration attribute whose name ends in Status, State, Result, Stage or Phase;
  • an …At / …By audit attribute;
  • an association that the rule's own XPath uses for ownership.
• Message. It names the fix: read on all members, write on input members only, and gate the rule on the initial state in its XPath.

Configuration states. These changed after review; see "Unset option: why it is not blocking" below.

Option state	What exec / lint-gate sees	What sync shows
absent (not decided yet)	nothing	a NOTE on every sync: the exact YAML to add, the rule for "none", and the re-baseline step
"A, B"	findings	—
"none"	nothing; the rule is off	—
a YAML list (mxcli passes a list as None), blank, an unknown role, or a catalog that is not FULL	one _rule finding (PASS-BLIND); the message is under 160 characters and names .claude/lint-config.yaml or REFRESH CATALOG FULL	—

"none" switches a security rule off. So the README, the rule header, the blank-value _rule message and the sync NOTE all say the same thing: it is set only on the user's answer, asked in chat and recorded in PROJECT.md, never to silence a finding.

Re-baselining. The first configured run jumps SEC014 from 0 to N, and lint-gate would blame that security-tier rise on whichever script runs next. The README, CHANGELOG and NOTE therefore say to re-baseline right after configuring, once the user has seen the findings: bin/lint-gate.sh --update-baseline --reason "SEC014 configured" --approved-in-chat. If #308 lands, its FIRST-SEEN handling covers part of this too.

Unset option: why it is not blocking. As first pushed, an absent option was a _rule finding. That would have made every synced project's exec.sh exit 1 (LINT BLIND) until someone edited a config file, which is the #229 pattern from an unconfigured CONV020. Moving the fix into the message (point 1) does not change that the exec still exits 1. So the undecided state now lives in bin/sync-project.sh, as a NOTE printed on every sync (new bin/lib/sec014-notice.sh).

• It is a NOTE rather than a warn(). tests/wave2/test-bug12-sync.sh T0 requires a pristine scaffold to sync with exit 0 and no warning under --strict. The warn() version failed T0; the NOTE version passes 61/61.
• I did not add an informational lint row. A counted row in an existing baseline would itself be a 0 → 1 security-tier rise on the next exec.
• A value that someone wrote but that is unusable is still blocking. The issue's intent was "never a silent pass"; for the absent case that pass is now named on every sync rather than on every exec.
• Backlog row 49 (new Batch 6) is linked to row 14, which covers the anonymous role only.

#267: CONV009 now reads its options

Problem. Stock conv009_max_microflow_objects.star (0.17.0–0.26.0) hard-codes 15 and never calls get_option(). The maxObjects: 20 example in the generated lint-config.yaml therefore does nothing.

Fix.

• A toolkit-owned CONV009 reads maxObjects and countLoopBodies, and ships through the replace-the-stock path.
• Default kept at 15 (raising it is a maintainer call). Setting maxObjects: 20 with countLoopBodies: true matches microflow-preflight.md.
• An unusable value gives a _rule finding.
• After review, the "every flow reports 0 objects" self-check fires only if activities_for() finds a real object (not a start, end or merge event) in a zero-count flow. An early greenfield model with empty microflows is no longer reported blind (new fixture).
• STOCK-HASHES.txt gains conv009 for v0.17.0, v0.24.0 and v0.25.0, plus a full v0.26.0 set. I captured them with mxcli init into empty directories from the official mxcli-linux-amd64 release assets; the same run reproduced every hash already in the file.
• skills/lint-that-actually-runs.md now says that options: reaches only rules that call get_option(), and that a list value arrives as None.
• Backlog row 50.

Also: turning a toolkit rule off (TXT002)

The README and the TXT002 header now say that ISO dates are a toolkit opinion, not a Mendix rule. A project whose display standard is not ISO sets rules: TXT002: enabled: false in lint-config.yaml and records the decision in PROJECT.md. It must never delete the file, because sync re-installs it. Verified on mxcli 0.26.0: a toolkit rule with 1 finding gave 0 once disabled. The README points to #308's .claude/lint-rules-disabled.txt for stopping installation once that PR lands.

Evidence

Unit tests. tests/lint-rules/test-batch4-rules.sh: 32/32. It fails on master, where the rules are missing and the harness has no get_option. The stock conv009 also fails the maxObjects: 20 case. The harness gained mocks for get_option (with mxcli's conversion: a list becomes None), permissions_for, attributes_for, user_roles and role_mappings.

Field run (official mxcli 0.26.0, scratch copies of two models, catalog FULL):

Rule	Configuration	Model 1 (21 modules)	Model 2 (9 modules)
CONV009, stock	default 15	5	—
CONV009, stock	maxObjects: 20	5 (bug reproduced)	—
CONV009, toolkit	default 15	5	0
CONV009, toolkit	maxObjects: 10	10	0
CONV009, toolkit	maxObjects: 20	5	0
CONV009, toolkit	20 + countLoopBodies	6	0
SEC014	option absent	0	0
SEC014	the model's external-style role	1 (true positive, same shape as #268)	—
SEC014	every role (positive control)	7	0
SEC014	list / misspelt role	1 _rule each	—

• A SQL replay of the SEC014 logic over the catalog gives the same 7 / 0.
• Model 2 has no external role, so its zeros are a null result.
• Both rules also load and give the same counts on mxcli 0.17.0 and 0.24.0. SEC014 avoids associations(), which does not exist before 0.25.0 and stops the file loading.

Checks run

Check	Result
tests/lint-rules/test-batch4-rules.sh	32/32
tests/lint-rules/test-batch3-rules.sh	23/23
tests/lint-rules/test-batch2-rules.sh	16/16
tests/lint-rules/test-batch1-rules.sh	29/29
tests/lint-rules/test-ux-rules.sh	36/36
tests/test-lint-delivery.sh	ALL GREEN
tests/wave2/test-stock-hashes.sh	35/35; T4 live 40/40 on each of v0.17.0, v0.24.0, v0.25.0, v0.26.0
tests/wave2/test-sec014-notice.sh	14/14; fails on master
tests/wave2/test-bug12-sync.sh	61/61 (master 61/61)
tests/wave2/test-dryrun-writes-nothing.sh	6/6
tests/wave2/test-sync-dup-heading-exit.sh	6/6
tests/wave2/test-ritual-slim.sh	17/17
tests/wave2/test-slim-claude-md.sh	16/16
tests/wave2/test-change-log.sh	39/39
check-scripts, check-portability, check-no-private-citations, render-routing --check, check-no-client-data (no denylist), check-pr-discipline origin/master	all clean

origin/master (#313) is merged in, with all CHANGELOG lines kept.

Risks

• Ownership detection. A written member that is not one of the entity's own attributes is treated as an association. An inherited attribute would be misread this way, but it only matters if the XPath also names it.
• write * on input-only entities. SEC014 flags write * even on an entity whose members are all input fields. That is deliberate per the issue; a reviewer can accept it.
• Undecided projects. Until a project sets external_roles, SEC014 checks nothing on exec. The sync NOTE is the only reminder, and it does not fail --strict.

Field run: done (above). Status for both rules stays drafted until a second project reports.

Re-review round 2 (merges #308)

origin/fix/lint-receipt-check (#308) is merged into this branch. Its lint-rules/README.md conflict is resolved into a single "Opting out of a rule" section. That opt-out story is now the same everywhere:

1. rules: <ID>: enabled: false in .claude/lint-config.yaml stops a rule reporting. This is the preferred route. The .star file stays installed and keeps refreshing; verified on mxcli 0.26.0, where a rule with 1 finding gave 0 once disabled.
2. .claude/lint-rules-disabled.txt, one line per rule with a # reason:, stops sync installing a toolkit rule. Stock-seeded rules are refused; conv009 is now on that list with conv010, data_change_microflows and entity_business_key.
3. Never delete the file. Deleting it reads as a re-seed and makes every exec report LINT BLIND.

Where this now appears:

• fix(lint-gate): reverted-to-stock rules stop the run as BLIND, not a rise (#264); BUG-156 + preflight row 28 (#263) #308's TXT002 example no longer says "and delete the file".
• The TXT002 header points to these two mechanisms.
• The "or remove this rule deliberately" suggestion in 11 rule files now reads: have the user turn it off (enabled: false, recorded in PROJECT.md).
• The "once that PR is merged" wording is gone.
• rules: SEC014: enabled: false is documented as the same user decision as external_roles: "none": asked in chat and recorded in PROJECT.md.

SEC014 undecided is no longer silent in practice. While SEC014 is installed and has no external_roles under its key, project-bin/lint-gate.sh prints one stderr line on every run: note: SEC014 not configured — set .claude/lint-config.yaml rules: SEC014: options: external_roles (ask the user; 'none' is their decision). It changes no exit code and adds no lint row.

bin/lib/sec014-notice.sh and the lint-gate check both count external_roles, or enabled: false, only under the SEC014 key. The same awk is inlined in lint-gate because a project has no bin/lib. Cases covered in the fixture:

• external_roles under another rule, or at top level, does not count;
• an inline map, a quoted key, and a commented line all handled.

tests/wave2/test-sec014-notice.sh now has 24 cases. They include one note line, no note once configured or when SEC014 is not installed, and the same exit code either way.

Known gap (outside my files). exec.sh captures lint-gate output and shows it only on a failure, so the note does not appear during a clean exec. The sync NOTE and direct lint-gate runs carry it. A one-line exec.sh follow-up would surface it (grep '^note: SEC014' "$_lo").

Round 2 checks:

Check	Result
tests/lint-rules/test-batch4-rules.sh	32/32
tests/lint-rules/test-batch3-rules.sh	23/23
tests/lint-rules/test-batch2-rules.sh	16/16
tests/lint-rules/test-batch1-rules.sh	29/29
tests/lint-rules/test-ux-rules.sh	36/36
tests/test-lint-delivery.sh	ALL GREEN
tests/wave2/test-sec014-notice.sh	24/24
tests/wave2/test-lint-receipt-revert.sh	55/55
tests/wave2/test-stock-hashes.sh	35/35
tests/wave2/test-lint-gate-accept.sh	20/20
check-scripts, check-portability, check-no-private-citations, render-routing --check, check-no-client-data, check-pr-discipline	all clean

Closes #268
Closes #267

🤖 Generated with Claude Code

https://claude.ai/code/session_01VJgWP5vEoAsNsJYqCDMGNw

---

Generated by Claude Code

[MendixMau]

Landed on master as part of the integration squash #329 (commit 31e90ae), after independent review — its Review: line is in that commit message. Closing as superseded.

---

Generated by Claude Code