Skip to content

fix(policy): trim the memory service prefix from condition key names - #252

Merged
harshavardhana merged 2 commits into
minio:mainfrom
harshavardhana:fix/memory-condition-key-name
Aug 1, 2026
Merged

fix(policy): trim the memory service prefix from condition key names#252
harshavardhana merged 2 commits into
minio:mainfrom
harshavardhana:fix/memory-condition-key-name

Conversation

@harshavardhana

Copy link
Copy Markdown
Member

Follow-up to #251, which added memory:prefix and memory:max-keys. Both were
inert as shipped.

A condition key's service prefix is stripped before it looks up the request
value — toTrim covers aws, jwt, ldap, sts, svc, s3, s3tables
so s3:prefix reads the request's prefix. memory was missing:

s3:prefix     .Name() = "prefix"
memory:prefix .Name() = "memory:prefix"
evaluate against args[prefix]=alpha -> false

The key parsed, validated, and appeared in the action condition map, so a policy
using it loaded cleanly — and then granted nothing, because the condition never
matched. That is the failure mode the key was added to prevent: a grant that
looks scoped and silently isn't.

After the fix:

memory:prefix .Name() = "prefix"
prefix=alpha    vs alpha* -> true
prefix=alphabet vs alpha* -> true
prefix=beta     vs alpha* -> false
prefix absent             -> false

Tests assert the request-name mapping for every service-prefixed key, not just
the memory ones, so the next service added here fails loudly rather than
shipping inert. Mutation-checked: removing memory from toTrim fails both.

A condition key's service prefix is stripped before it looks up the
request value, so "s3:prefix" reads "prefix". "memory" was missing from
that set, so memory:prefix kept its whole name and read a value nothing
populates.

The key parsed, validated and appeared in the action map, but evaluated
false against a real request -- so every statement carrying it granted
nothing. A condition that looks like it scopes a listing and instead
silently voids the grant is worse than not having the key.

Tests assert the request-name mapping for every service-prefixed key and
evaluate memory:prefix against real request values, including that an
absent prefix does not satisfy a scoped condition.
@coderabbitai

coderabbitai Bot commented Aug 1, 2026

Copy link
Copy Markdown

Warning

Review limit reached

@harshavardhana, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 30 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details
⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: 0d43a268-60b6-4488-a391-cf938435a506

📥 Commits

Reviewing files that changed from the base of the PR and between aa4efcb and d617655.

📒 Files selected for processing (2)
  • policy/condition/keyname.go
  • policy/condition/keyname_test.go

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

Copilot AI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This PR fixes policy condition evaluation for memory:-prefixed condition keys by ensuring the service prefix is trimmed before request-argument lookup, making memory:prefix and memory:max-keys effective rather than inert.

Changes:

  • Add memory to the set of service prefixes trimmed from condition key names.
  • Add unit tests intended to guard the key-name → request-argument mapping and to verify memory:prefix conditions evaluate against the real request prefix value.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File Description
policy/condition/keyname.go Adds "memory" to the toTrim prefix set so memory:* keys resolve to request argument names.
policy/condition/keyname_test.go Introduces tests for service-prefixed key name resolution and for memory:prefix condition evaluation behavior.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Comment thread policy/condition/keyname.go Outdated
Comment thread policy/condition/keyname_test.go Outdated
The test asserted six hand-picked keys, which does not deliver what it
claimed: a key added for a new service without extending toTrim would
still ship inert. It now sweeps AllSupportedKeys, so the next one fails
here and the message names the prefix to add.

Rewrite the Name doc comment to point at toTrim rather than enumerate
prefixes, which had already drifted -- it listed four of the seven.
@harshavardhana
harshavardhana merged commit 146b267 into minio:main Aug 1, 2026
11 checks passed
@harshavardhana
harshavardhana deleted the fix/memory-condition-key-name branch August 1, 2026 11:25
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants