codebase-archaeology

Score Breakdown

Your Submission

{
  "fixed_code": "export function evaluateAccess(\n  request: AccessRequest,\n  userRoles: string[],\n  roleDefinitions: Map<string, Role>,\n  denyRules: string[],\n  maxDepth: number\n): AccessDecision {\n  const permission = `${request.resource}:${request.action}`;\n  const wildcard = `${request.resource}:*`;\n\n  // Check deny rules first (deny takes priority)\n  for (const denyRule of denyRules) {\n    if (denyRule === permission || denyRule === wildcard) {\n      return { allowed: false, reason: \"Explicitly denied\", matchedRule: denyRule };\n    }\n  }\n\n  // Check allow rules\n  for (const role of userRoles) {\n    const allPerms = resolvePermissions(role, roleDefinitions, maxDepth, new Set());\n    if (allPerms.has(permission) || allPerms.has(wildcard)) {\n      return { allowed: true, reason: \"Permission granted via role\", matchedRule: permission };\n    }\n  }\n\n  return { allowed: false, reason: \"No matching permission\", matchedRule: null };\n}",
  "methodology": "1. Reviewed COMMIT_HISTORY.md to identify commits that modified src/auth/permissions.ts: commits 8d2680d6 (Add utility helper functions) and 42875900 (Optimize evaluateAccess edge cases). 2. Read the full source code of permissions.ts, the test file, and all related modules (session.ts, index.ts, config.ts, guard.ts). 3. Traced through each test case manually against the code logic. 4. Identified that commit 42875900 'Optimize evaluateAccess edge cases' is the buggy commit since it most recently modified the evaluateAccess function. 5. Found that the deny check logic was rewritten to iterate through resolved user permissions instead of directly checking deny rules against the request, which breaks wildcard deny rule matching and couples deny logic to role resolution unnecessarily.",
  "buggy_commit": "Optimize evaluateAccess edge cases",
  "bug_description": "The deny check in evaluateAccess iterates through all resolved user permissions and checks if each one is in the deny list AND matches the requested permission. This approach is incorrect because: (1) it fails when deny rules contain wildcards (e.g., 'docs:*') but the user's resolved permissions only contain specific permissions (e.g., 'docs:delete'), and (2) it unnecessarily couples deny rule checking to the user's role permissions when deny rules should apply regardless of what permissions a user has. The correct approach is to check deny rules directly against the requested permission and its wildcard form."
}