Skip to content

windows: deny entries rank as on the other platforms - #686

Merged
ronleizrowice-ant merged 1 commit into
mainfrom
fix/windows-deny-entries-rank-as-on-the-other-platforms
Oct 12, 2026
Merged

ronleizrowice-ant merged 1 commit into
mainfrom
fix/windows-deny-entries-rank-as-on-the-other-platforms

Conversation

@ronleizrowice-ant

Copy link
Copy Markdown
Collaborator

On Windows the filesystem lists and credentials.files become ACEs for the sandbox account. rankWindowsFsAccess ranks them against each other before srt-win is called, as on the other platforms.

  • denyWrite over allowWrite: an allowWrite at or beneath a denyWrite path is granted read and execute only.
  • credentials.files over both allow lists: an allowRead or allowWrite at or beneath an entry is not granted. The trust bundle is the only exception.
  • A mode: "mask" file is read-denied, as on macOS: an ACL cannot redirect a read.
  • A deny that one command brings in its customConfig is also stamped on the session's grants beneath it.

An allowRead beneath a denyRead stays readable.

Paths are compared as they resolve on disk, so links, junctions, 8.3 names and letter case make no difference. A UNC path is compared as spelled. No change to the helper.

What a configuration can notice

  • A write grant beneath a denyWrite keeps read and loses write.
  • A grant beneath a credentials.files entry is gone.
  • A masked file cannot be read, written or renamed. One that has hard links, or that the user cannot re-ACL, fails initialize() with the existing acl_stamp_failed, as a mode: "deny" entry does.

Testing

  • Unit rows of the ranking on every host, and the manager's calls under a platform spy. 33 mutations: 32 fail a test, one is equivalent.
  • Rows L1 to L14 and G10 run on the Windows jobs only, with the real helper and sandbox user. Each logs [winsrt Ln] ran: …. Their first run is this pull request's CI.

Merge order

#683's ESLint rule names the one fs.realpathSync.native call here. Whichever lands second settles it.

The ACEs set on an object come before the ones it inherits, so beneath a
DENY on a directory an ALLOW set further down is the one that counts. That
is the rank of allowRead over denyRead. rankWindowsFsAccess hands srt-win no
such ALLOW for the two opposite ranks: a write grant at or beneath a write
deny is a read grant, and a grant at or beneath a credentials.files entry is
left out. A masked file is read-denied, as on macOS. A deny that one command
brings is also stamped on the session's grants beneath it.

@imichaelmoore imichaelmoore left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

/stamp

@ronleizrowice-ant
ronleizrowice-ant merged commit 6b4fc1d into main Oct 12, 2026
23 of 24 checks passed
@ronleizrowice-ant
ronleizrowice-ant deleted the fix/windows-deny-entries-rank-as-on-the-other-platforms branch October 12, 2026 14:17
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