Content Selectors, Repository Targets, Fine-Grained Privileges, and Path-Level Authorization: Diagnostics, Failure Modes, Security, and Performance

1. Diagnostic sequence: authorization is an evidence problem

1. Preserve concise client status/body, requested URL/path, principal, and time.
2. Confirm Nexus version/edition/runtime and whether the server is writable.
3. Confirm the client is hitting the intended direct or group endpoint and authenticating as the expected user.
4. Inspect repository type/format/group membership.
5. Inspect the selector expression and Preview result.
6. Inspect every privilege and inherited role assigned to the principal.
7. Inspect matching asset path/metadata state.
8. Only then consider proxy/cache/upstream, database/blob/disk, logs/tasks/metrics if the symptom actually points there.
9. Change one smallest policy object and repeat the exact request.

2. Failure: selector matches more than intended

Intentionally compare these two expressions:

# BROKEN: can match /team-a-archive/
format == "raw" and path =^ "/team-a"

# REPAIRED: namespace delimiter is explicit
format == "raw" and path =^ "/team-a/"

Use Content Selector Preview against synthetic paths. If the broken selector matches an unintended asset, preserve that preview evidence. Fix the expression—not the blob path, database row, or client cache—and then repeat the authorization request.

3. Failure: UI visibility and direct read disagree

browse and read are different actions. Search visibility also involves nx-search-read. Therefore “I cannot see it in Browse” is not equivalent to “the server denies a direct GET.” Capture both:

curl -sS --netrc-file "$TA_AUTH"   -o "$LAB/evidence/direct-read.body"   -w 'direct-read http=%{http_code}\n'   "$HOSTED_URL/team-a/app/1.0.0/release.txt"   | tee "$LAB/evidence/direct-read.status"

curl -fsS --netrc-file "$NX_AUTH_FILE"   "$NX_URL/service/rest/v1/security/roles/academy-ch14-team-a-role"   > "$LAB/evidence/team-a-role.json"

If direct read works but browse/search does not, add only the missing browse/search privilege required by the intended UX. Do not grant wildcard repository access.

4. Failure: role inheritance expands access

A team user unexpectedly reads Team B. The selector itself is correct. Before editing it, inspect the user and every role. A broader inherited role, a default role, or a second direct role can authorize the request. Nexus privileges cannot “deny back” a grant from another role.

5. Intentionally broken example: broad group read defeats member precision

For a disposable Team A role, temporarily add the repository-wide read privilege for academy-ch14-group. Keep the direct hosted privilege narrow. Test Team B through both endpoints.

for base in "$HOSTED_URL" "$GROUP_URL"; do
  curl -sS --netrc-file "$TA_AUTH"     -o "$LAB/evidence/overbroad-$(basename "$base").body"     -w "$base team-b http=%{http_code}\n"     "$base/team-b/app/1.0.0/release.txt"     | tee -a "$LAB/evidence/overbroad-status.txt"
done

Expected causal interpretation: the direct hosted request remains denied by the narrow member policy, while the group request can succeed because the broad group privilege independently authorizes content surfaced through the group.

Repair: remove the broad group repository-view privilege and retain only academy-ch14-a-group-read. Repeat the same group GET. The Team B path should now be denied while Team A remains readable.

6. Failure: path assumptions copied from another format

Do not copy /team-a/ Raw logic into Docker, Maven, PyPI, or APT without checking current format semantics. Docker client and REST paths differ. Maven can use enhanced selector attributes but path remains predictable. PyPI and APT uploads may POST to the repository root, which prevents path selectors from restricting upload in the same way. A policy can be syntactically valid and still fail to enforce the intended write boundary for a particular protocol.

7. Failure: relying on UI visibility as security proof

Admin UI screens are not the request path used by a build agent. Always test the actual principal, endpoint, HTTP method, and path. Conversely, do not conclude that an item shown in a search result is downloadable; browse/search and read are distinct grants.

8. When logs and infrastructure matter

If both allowed and denied requests return the same unexpected transport failure, authorization may not be the problem. Preserve HTTP status and Nexus request/log evidence, then separate TLS/reverse-proxy errors, server read-only state, database latency, blob IO, and JVM pressure from permission decisions. Performance tuning is not a fix for a 403 caused by a selector mismatch.

9. Security-sensitive changes

10. Knowledge check

11. Summary and next step

The diagnostic method is now deterministic: prove identity and endpoint, inspect selector and role composition, then reproduce the exact request before changing policy. Lesson 5 combines this into a two-team checkpoint with an intentionally overbroad group grant and a final authorization matrix.

Official references and version notes

• Sonatype: Content Selectors — CSEL syntax, preview, supported formats, performance guidance, and upload limitations.
• Sonatype: Privileges — repository view versus content-selector privileges, actions, additive grants, and group semantics.
• Sonatype: Access Control — RBAC object model.
• Sonatype: Security Management API and API Reference.
• Sonatype: Changes During the Upgrade Process — Nexus Repository 2 repository targets become Nexus Repository 3 content selectors.
• Self-Hosted Feature Matrix — Repo Targets / Content Selectors are Community and Pro capabilities.
• Sonatype: Database Options — coordinate-based selectors are deprecated with PostgreSQL and no longer supported.
• Sonatype verified Nexus Docker image tags.

Version-sensitive statements were rechecked on 2026-08-26. Sonatype's verified container registry exposes Nexus Repository 3.95.2 as the current latest image line. The mandatory chapter path uses Community-compatible content selectors, local users/roles, Raw hosted/group repositories, and the self-hosted security APIs. It does not require Pro user tokens, SAML/OIDC, HA, staging, Repository Firewall, or deployment to a group repository.