-
-
Notifications
You must be signed in to change notification settings - Fork 15
Address review comments on libuv patch #41
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
Conversation
|
I'm testing Yggdrasil build here: JuliaPackaging/Yggdrasil#10316 |
This is to test JuliaLang/libuv#41
|
Julia testing PR: JuliaLang/julia#57126 |
This is to test JuliaLang/libuv#41
This is to test JuliaLang/libuv#41
This is to test JuliaLang/libuv#41
This is to test JuliaLang/libuv#41
4eb819b to
772bf28
Compare
|
@vtjnash This passed tests in https://buildkite.com/julialang/julia-master/builds/44361#0194cf76-9df8-4206-bbb2-6bcbbade9ff3, so I've rebased to clean up history a bit and I think it's ready to merge now. |
|
One thing to note, the following tests needed to be adjusted: |
|
CI did something weird there it seems. Can you rebase? I just pushed the various recent commits to fix CI from upstream |
772bf28 to
12c6211
Compare
|
I see; that wasn't actually your fault. I've fixed the branch content mistake, so now it should go through. |
No longer shy away from using `AccessCheck()` for simple `W_OK`/`R_OK` checks; use it for all calls unconditionally. It turns out that `F_OK` is supposed to only check for path existence, and because it is `0x00`, it ends up confusing the Windows APIs below where it looks like we're asking for the null set of permissions, so handle that as well.
Because our ACL implementation does not have the required flexibility to represent situations such as `0o757` due to the permissions ordering that Windows naturally applies, we simply do not allow the `other` entity to have permissions that the `group` entity does not have. This causes `chmod(0o757)` to be transparently mapped to `chmod(0o755)`, as an example.
Previously, we would apply permissions only to groups that we were a part of, but we should apply our "other" permissions to groups that we are not a part of.
So we must handle that appropriately in this helper function
* Use `DWORD` instead of `mode_t` on Windows. It's not needed to use `mode_t` here, and it just confuses VS.
* Define `S_IRWXU` and others if not already defined.
* When compiling on my windows testing box, I get the error:
```
error: initialization of 'SECURITY_INFORMATION' {aka 'long unsigned int'} from 'void *' makes integer from pointer without a cast [-Wint-conversion]
2317 | SECURITY_INFORMATION si = NULL;
```
12c6211 to
46ca7fe
Compare
|
|
||
| DWORD sdLen = 0, err = 0, tokenAccess = 0, desiredAccess = 0, | ||
| grantedAccess = 0, privilegesLen = 0; | ||
| SECURITY_INFORMATION si = (SECURITY_INFORMATION)NULL; |
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.
SECURITY_INFORMATION is a DWORD, we shouldn't be converting from a ptr.
This is a new version of #16 based against
julia-uv2-1.48.0.This hopefully addresses the two actionable comments from
@erw7. In particular:We use
AccessCheck()unconditionally on duringaccess().I don't allow
otherto have more permissions thangroup. This is necessary because in cases likechmod("foo", 0o757), theDENYentry forgroup(necessary becauseotherhas more permissions thangroup) ends up blocking the user, due to the fact thatuserbelongs togroup. So I just mask out any bits thatotherhas thatgroupdoesn't, so0o757turns into0o755. You can still have0o057, or0o700or whatever, it's just the case whereotherhas bits thatgroupdoesn't that gets fixed up.