Three access-control fences have no test that fails without them

Open
  • Is something wrong?
#43 1 comment 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
3/5
Estimated time
1-2 days
Newbie friendliness
68/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Domain
authorization, security, testing-qa

Research direction

Start with experiments/access/access-control-v1 and the tests under experiments/test/access-control-v1; run the provided python3 tools/daml_mutate.py command to establish the baseline. Add named tests covering the three listed access-control fences, then verify that mutating each condition to True makes a test fail while the unmutated suite passes.

Written by the indexing model from the issue text.

Description

Answering the invitation in your forum thread — "Test it… Clone the repos… open an issue with how it works for what you're building, or where it should change."

I built a mutation-testing harness for Daml authorisation fences and pointed it at experiments/access/access-control-v1 at 7696749. It makes each assertMsg condition vacuous (cond → True), rebuilds the DAR, and requires a named test to go red.

Seven fences, 17 scripts, all green at baseline. Four are covered. Three are not:

Line Fence Message
139 assertMsg eRoleAdminMismatch (grant.admin == admin) AccessControl: grant admin is not the expected authority
183 assertMsg eRoleAdminMismatch (grant.admin == admin) same
289 assertMsg eRoleAssigneeMismatch (grant.account == caller) AccessControl: grant does not name the caller (impersonation)

Replace any one of those conditions with True and all 17 scripts still pass.

Line 139 guards RoleAdmin_RevokeRole — it is what stops one admin revoking a grant issued by a different admin.

Verified by hand, because the harness was wrong twice first

I don't want to file a result I only got from my own tool, so each was checked manually:

  • daml build exits 0 (the mutation compiles)
  • the DAR hash changes: 611c35e1275822a8… → 2c8722cd25e2ac62…
  • daml test then reports 17 ok, 0 failed

That middle step matters. My first attempt broke the build with bad indentation, which left the previous DAR in place — so the suite passed against code the mutation never reached, and it read exactly like a finding. Worth knowing if you ever try this yourselves.

The harness also had two real bugs, both found only by running it on code I didn't write: deleting a fence's line breaks the enclosing do block when it's the last statement, and I was reading daml test's exit code as though it meant "compiled" — which reported four covered fences as compile failures.

Why I think this is worth a look despite experiments/

I've read experiments/README.md and I know these aren't production-ready. Filing anyway because the top-level README says they are tested in CI, and this is the specific gap CI can't see: daml-lint reads the source, daml-props generates inputs, daml-verify proves stated properties. None of them can tell you the test guarding a fence is incapable of failing.

Reproducing
python3 tools/daml_mutate.py \
  --src experiments/access/access-control-v1 \
  --test experiments/test/access-control-v1

Harness (MIT): https://github.com/dominicrume/cantor8_kya_rails/blob/main/tools/daml_mutate.py

Entirely possible these are deliberate, or that I've misread something. It's been wrong twice already today — happy to be told it's three.

Dominant language
Haskell
Stars
5
Forks
0
Avg merge
1d 36m
Merged PRs (30d)
11

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from OpenZeppelin/canton-contracts

All issues in OpenZeppelin/canton-contracts

Similar issues

More Haskell issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.