Skip to content
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

lib/std: Make usage of PermissionDenied & AccessDenied consistent #23007

Open
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

rootbeer
Copy link
Contributor

This PR (mostly) consistently maps .ACCES into errors.AccessDenied and .PERM into errors.PermissionDenied. These two similar error codes are a POSIX thing where EACCES is returned if the file mode bits (user/group/other rwx bits) disallow access. Whereas EPERM is returned if something else denies access (e.g., immutable bit, SELinux, capabilities, etc). Most of the change is straight-forward and starts in the lib/std/posix.zig code, and propagates up to the std.os.* and std.fs.* layers that pass the Posix errors on. There are a couple pre-existing exceptions to this general rule where more "useful" errors are returned (e.g., errors.Locked for EACCES in fcntl).

POSIX makes this extra confusing because the EACCES errno stringifies as "Permission Denied" (EPERM stringifies as "Operation Not Permitted"). I think it is clearer to map the Zig made up names to the errno token, thus AccessDenied for EACCES and PermissionDenied for EPERM, but I could be persuaded to use a different mapping. OTOH, I think it would be even less confusing if Zig didn't try to "fix" the errno names and just returned errors.EACCES and errors.EPERM, but that is not this PR.

I changed some Windows code (both in posix.zig and not) to consistently map the Windows ACCESS_DENIED error code to errors.AccessDenied. My general rule here is that the Zig error codes should reflect the platform's error as directly as possible unless there is a good reason.

Fixes #16782

Windows defines an `ACCESS_DENIED` error code.  There is no
PERMISSION_DENIED (or its equivalent) which seems to only exist on POSIX
systems.  Fix a couple Windows calls code to return `error.AccessDenied`
for `ACCESS_DENIED` and to stop mapping AccessDenied into
PermissionDenied.
…rmissionDenied

Use error.AccessDenied for permissions (rights) failures on Wasi
(`EACCES`) and error.PermissionDenied (`EPERM`) for systemic failures.
And pass-through underlying Wasi errors (PermissionDenied or AccessDenied)
without mapping.
This PR consistently maps .ACCES into AccessDenied and .PERM into
PermissionDenied.  AccessDenied is returned if the file mode bit
(user/group/other rwx bits) disallow access (errno was `EACCES`).
PermissionDenied is returned if something else denies access (errno was
`EPERM`) (immutable bit, SELinux, capabilities, etc).  This somewhat
subtle distinction is a POSIX thing.

Most of the change is updating std.posix Error Sets to contain both
errors, and then propagating the pair up through caller Error Sets.

Fixes ziglang#16782
@rootbeer rootbeer force-pushed the posix-eaccess-eperm branch from 6fc21ea to bcb07ec Compare February 24, 2025 22:32
@alexrp alexrp self-requested a review February 25, 2025 01:52
@rootbeer
Copy link
Contributor Author

The x86_64-macos-release failure is:

+ stage3/bin/zig build test docs --zig-lib-dir /Users/runner/work/zig/zig/build/../lib -Denable-macos-sdk -Dstatic-llvm -Dskip-non-native --search-prefix /Users/runner/zig+llvm+lld+clang-x86_64-macos-none-0.14.0-dev.1622+2ac543388
test
+- test-cases
   +- run pic_linux
      +- zig build-exe pic_linux Debug riscv32-linux failure
error: the following command terminated unexpectedly:
/Users/runner/work/zig/zig/build/stage3/bin/zig build-exe -fllvm -fPIC -ODebug -target riscv32-linux -mcpu baseline -Mroot=/Users/runner/work/zig/zig/zig-local-cache/o/21e8c1356c94e88836867bbb5dd32630/tmp.zig -lc --cache-dir /Users/runner/work/zig/zig/zig-local-cache --global-cache-dir /Users/runner/work/zig/zig/zig-global-cache --name pic_linux -L /Users/runner/zig+llvm+lld+clang-x86_64-macos-none-0.14.0-dev.1622+2ac543388/lib -I /Users/runner/zig+llvm+lld+clang-x86_64-macos-none-0.14.0-dev.1622+2ac543388/include --zig-lib-dir /Users/runner/work/zig/zig/build/../lib/ --listen=- 
Build Summary: 8281/8576 steps succeeded; 291 skipped; 1 failed; 38909/40214 tests passed; 1305 skipped

I believe this is failing to build an executable for the ./test/cases/pic_linux.zig test case, which is just a simple pub fn main() void{} test that is used to make sure a bunch of targets can build -fPIC -lc -fllvm executables. I don't think this has anything directly to do with my changes here (though I did tweak the returned error set for spawnZ on Darwin). But I also don't see this failure reported anywhere else.... I know the Windows CI runner is creating drama today, but I didn't think the MacOS builds were having problems.

Once the other CI builds for this PR complete, I'll rebase this PR and push another version and hope this goes away. If anyone wants me to file a bug or dig into this failure more (or knows what's going on), please let me know.

@alexrp
Copy link
Member

alexrp commented Feb 25, 2025

That could just be OOM fallout. That particular test hasn't had any issues since I introduced it.

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.

error.PermissionDenied vs error.AccessDenied
2 participants