-
Notifications
You must be signed in to change notification settings - Fork 29.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
permission: handle case-sensitive file systems #47269
permission: handle case-sensitive file systems #47269
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this affect both --allow-fs*
and process.permission.deny()
?
If so, assuming a system uses a mix of case-sensitive and case-insensitive file systems and/or directories, making process.permission.deny()
work somewhat reasonably requires case-insensitivity (in order to over-approximate the set of paths that access is being denied to), but then suddenly the paths specified in --allow-fs*
are also matched case-insensitively (thus also over-approximated)?
Without forcing users to go through the trouble of managing all of this manually, would it not be safer to over-approximate the set of denied paths and to under-approximate the set of allowed paths?
path.begin(), | ||
path.end(), | ||
path.begin(), | ||
[](unsigned char c) -> unsigned char { return std::tolower(c); }); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
cc @bnoordhuis, I am not sure if this is related to the concern in #47105 (comment).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm
I don't think we can do much more.
@tniessen I'm not sure if I understand, but, the flag you're referring to is designed to work with File System permissions (also known as |
What I mean is that, based on my understanding of this flag, if I allow access to
A simple option might be to remove
|
See the following code: $ ls ~/foo/
bar
$ cat ~/foo/bar
hello world
$ ./node --experimental-permission --allow-fs-read=/Users/rafaelgss/ --no-permission-case-sensitive
(node:51672) ExperimentalWarning: Permission is an experimental feature
(Use `node --trace-warnings ...` to show where the warning was created)
Welcome to Node.js v20.0.0-pre.
Type ".help" for more information.
>
Access to FileSystemOut is restricted.
REPL session history will not be persisted.
> const fs = require('fs')
undefined
> fs.readFileSync('/Users/rafaelgss/foo/bar').toString()
'hello world\n'
> process.permission.deny('fs.read', ['/Users/rafaelgss/foo/bar'])
true
> fs.readFileSync('/Users/rafaelgss/foo/bar').toString()
Uncaught Error: Access to this API has been restricted
at Object.openSync (node:fs:587:26)
at Object.readFileSync (node:fs:458:35) {
code: 'ERR_ACCESS_DENIED',
permission: 'FileSystemRead',
resource: '/Users/rafaelgss/foo/bar'
}
> fs.readFileSync('/Users/rafaelgss/index.cjs').toString()
"console.log('oi')\n" We keep 2 trees in the FSPermission, one for granted resources and one for denied (in runtime) resources, therefore if you want to deny a resource inside a granted wildcard, you can. Also, note that Is this behavior you are expecting? If yes, we should be fine. |
That's not what I meant. Let me rephrase my question again:
If that means that all path comparisons are case-insensitive by default, doesn't that mean that you also (implicitly) granted access to |
That's correct. But, at this point, I was considering it as a known limitation. In any case, I think we'll reach a consensus in #47105 to remove the |
Closing it in favor of #47335 |
Fixes #47105
This PR introduces a new cli flag that allows the user to explicitly set how FSPermission will handle the paths (case-sensitive or not).
As previously discussed, this also shows a feature limitation since you can mount a file system using a custom configuration (case-sensitive on
/home/user1
and case-insensitive on/home/user2
). However, this will be categorized as a known limitation and is likely to be discussed at nodejs/security-wg#898 when enabling per-file configuration.