accessSync not throwing error when no permissions in Windows 11

[NicoNekoru]

Version

v18.7.0

Platform

Microsoft Windows NT 10.0.25158.0 x64

Subsystem

fs

What steps will reproduce the bug?

fs.accessSync('C:\\Windows', fs.constants.W_OK)
fs.access('C:\\Windows', fs.constants.W_OK, () => { throw "Cannot write to 'C:\\Windows'" })

How often does it reproduce? Is there a required condition?

Reproduces 100% of the time

What is the expected behavior?

The expected behavior was to throw an EPERM error

What do you see instead?

Returns undefined and doesn't throw an error like expected.

Additional information

No response

[WillianAgostini]

Because fs.access is not and Synchronously or Asynchronously function, so your code is not awaiting the execution of this function before continuing.

So if the issue continues with fs.accessSync, please show complete code.
Does it happen only in v18.7.0 version?

[NicoNekoru]

@WillianAgostini sorry for being unclear, my issue only occurs with accessSync while access works as intended.

test.mjs

import { access, accessSync, constants } from 'fs'

await access('C://Windows', constants.W_OK, () => console.error(`Cannot write (access)`))

try { accessSync('C://Windows', constants.W_OK) }
catch (e) { console.error('Cannot write (accessSync)') }

Expected output:

Cannot write (access)
Cannot write (accessSync)

Actual output

Cannot write (access)

I initially had this issue in 16.9.0 but I assumed that my version may have been outdated so I updated to 18.7.0

[theanarkh]

I think because the process have the write permission on C://Windows ?.
change
access('C://Windows', constants.W_OK, () => console.error('Cannot write (access)'))
to
access('C://Windows', constants.W_OK, (err) => { err && console.error('Cannot write (access)'); } ).
and have a try.

[NicoNekoru]

@theanarkh When running your snippet I end up with no output. I know my process does not have write permissions on C;\\Windows since if I add the line

writeFileSync('C://Windows/test.txt', 'test')

I am given the expected EPERM error

node:fs:585
  handleErrorFromBinding(ctx);
  ^

Error: EPERM: operation not permitted, open 'C://Windows/test.txt'
    at Object.openSync (node:fs:585:3)
    at writeFileSync (node:fs:2153:35)
    at file:///C:/Users/Nico/Desktop/test.mjs:4:1 {
  errno: -4048,
  syscall: 'open',
  code: 'EPERM',
  path: 'C://Windows/test.txt'
}

[bnoordhuis]

What does "no permissions" mean? Keep in mind access() is not aware of Windows ACLs.

[NicoNekoru]

@bnoordhuis clearly it is aware of the process' permissions to some degree if access is working as expected.

My issue is with accessSync which is not erroring as expected unlike its non-synchronous counterpart

[bnoordhuis]

That was already pointed out by the @theanarkh - your asynchronous version has a bug. The other part of the story is that access() and accessSync() don't know about Windows ACLs and report success when the ACL will in fact block access.

Having said that, if you're using access() (whether sync or async) to determine whether you can write to a location, you're doing it wrong - just try to write and handle the error. Look up TOCTOU bugs.

[NicoNekoru]

@bnoordhuis Hmm thanks for the info, I've been using that alternative regardless.

I've just reread the docs on fs.access and it looks like I've completely misinterpreted it, sorry about that.

Would I be correct to say that accessSync does not work at all on windows then? If so that seems very unclear on the docs. The example use case for accessSync in the docs was

try {
  accessSync('etc/passwd', constants.R_OK | constants.W_OK);
  console.log('can read/write');
} catch (err) {
  console.error('no access!');
}

although a similar Windows translation could be

try {
  accessSync('C:\\Windows\\System32\\cmd.exe', constants.R_OK | constants.W_OK);
  console.log('can read/write');
} catch (err) {
  console.error('no access!');
}

which does not produce the same behavior.

---

TL;DR

access() is not aware of Windows ACLs.

1. Why isn't this stated on the docs?
2. What is the point of using access() on Windows? Does it not just behave like exists() then?
3. What is stopping access from being able to access Windows ACLs?
4. Are there any cmdlets that can check permissions of the process? Is it possible to make one if there isn't (os.userInfo() can work for this right?)

[WillianAgostini]

It has already been discussed on #2949 (comment).

[bnoordhuis]

Exactly. I'll close this out but to answer two of OP's questions:

Why isn't this stated on the docs?

It is.

What is stopping access from being able to access Windows ACLs?

TOCTOU - the ACL can change after the check. More generally, you can't really know what ACL applies until you actually try it.