Fix EXEC permission of the volume mount when calling mmap with PROT_EXEC #11358
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). View this failed invocation of the CLA check for more information. For the most up to date status, view the checks section at the bottom of the pull request. |
|
@nixprime Hey Jamie! Could you please help us review this pull request when you get time? Thank you! |
ayushr2
reviewed
Jan 14, 2025
ayushr2
reviewed
Jan 15, 2025
nixprime
reviewed
Jan 15, 2025
Yhinner
force-pushed
the
xuzhoyin-mmap-fix
branch
from
d163dcb to
3452c7b
Compare
|
Please squash your commits, other than that, looks good. |
Yhinner
force-pushed
the
xuzhoyin-mmap-fix
branch
from
3452c7b to
191b53d
Compare
ayushr2
approved these changes
Jan 27, 2025
copybara-service bot
pushed a commit
that referenced
this pull request
Jan 27, 2025
## Background This is Xuzhou (Joe) from `Snowflake Inc`. We are currently working on utilizing gVisor internally as our secured sandboxing mechanism. We have met in-person with gVisor team last October sharing our use case and experiences with the gVisor team. As part of the meeting, we (Snowflake team) committed to contribute our internal fixes/improvements back to the upstream. As part of compatibility testing with our previous mechanism, we found some behavior discrepancies between gVisor-emulated kernel and native linux kernel when making `mmap` system calls. Thus wanted to raise a pull request and see if this makes sense. ## Issue we observed On native linux kernel, when calling `mmap` syscall with PROT_EXEC on a file, linux kernel checks if the volume/file system backing the file is executable (ie. Has `NOEXEC` flag or not). If the volume has NOEXEC flag set, the syscall will fail with EPERM. However, this behavior is not observed when running under gVisor. Instead, gvisor allows this system call to be made without any issue. Thus this pull request aims to bring the same parity to gvisor implemented mmap syscall. FUTURE_COPYBARA_INTEGRATE_REVIEW=#11358 from Snowflake-Labs:xuzhoyin-mmap-fix 191b53d PiperOrigin-RevId: 720236462
copybara-service bot
pushed a commit
that referenced
this pull request
Jan 28, 2025
## Background This is Xuzhou (Joe) from `Snowflake Inc`. We are currently working on utilizing gVisor internally as our secured sandboxing mechanism. We have met in-person with gVisor team last October sharing our use case and experiences with the gVisor team. As part of the meeting, we (Snowflake team) committed to contribute our internal fixes/improvements back to the upstream. As part of compatibility testing with our previous mechanism, we found some behavior discrepancies between gVisor-emulated kernel and native linux kernel when making `mmap` system calls. Thus wanted to raise a pull request and see if this makes sense. ## Issue we observed On native linux kernel, when calling `mmap` syscall with PROT_EXEC on a file, linux kernel checks if the volume/file system backing the file is executable (ie. Has `NOEXEC` flag or not). If the volume has NOEXEC flag set, the syscall will fail with EPERM. However, this behavior is not observed when running under gVisor. Instead, gvisor allows this system call to be made without any issue. Thus this pull request aims to bring the same parity to gvisor implemented mmap syscall. FUTURE_COPYBARA_INTEGRATE_REVIEW=#11358 from Snowflake-Labs:xuzhoyin-mmap-fix 191b53d PiperOrigin-RevId: 720236462
copybara-service bot
pushed a commit
that referenced
this pull request
Jan 29, 2025
## Background This is Xuzhou (Joe) from `Snowflake Inc`. We are currently working on utilizing gVisor internally as our secured sandboxing mechanism. We have met in-person with gVisor team last October sharing our use case and experiences with the gVisor team. As part of the meeting, we (Snowflake team) committed to contribute our internal fixes/improvements back to the upstream. As part of compatibility testing with our previous mechanism, we found some behavior discrepancies between gVisor-emulated kernel and native linux kernel when making `mmap` system calls. Thus wanted to raise a pull request and see if this makes sense. ## Issue we observed On native linux kernel, when calling `mmap` syscall with PROT_EXEC on a file, linux kernel checks if the volume/file system backing the file is executable (ie. Has `NOEXEC` flag or not). If the volume has NOEXEC flag set, the syscall will fail with EPERM. However, this behavior is not observed when running under gVisor. Instead, gvisor allows this system call to be made without any issue. Thus this pull request aims to bring the same parity to gvisor implemented mmap syscall. FUTURE_COPYBARA_INTEGRATE_REVIEW=#11358 from Snowflake-Labs:xuzhoyin-mmap-fix 191b53d PiperOrigin-RevId: 720236462
copybara-service bot
pushed a commit
that referenced
this pull request
Jan 29, 2025
## Background This is Xuzhou (Joe) from `Snowflake Inc`. We are currently working on utilizing gVisor internally as our secured sandboxing mechanism. We have met in-person with gVisor team last October sharing our use case and experiences with the gVisor team. As part of the meeting, we (Snowflake team) committed to contribute our internal fixes/improvements back to the upstream. As part of compatibility testing with our previous mechanism, we found some behavior discrepancies between gVisor-emulated kernel and native linux kernel when making `mmap` system calls. Thus wanted to raise a pull request and see if this makes sense. ## Issue we observed On native linux kernel, when calling `mmap` syscall with PROT_EXEC on a file, linux kernel checks if the volume/file system backing the file is executable (ie. Has `NOEXEC` flag or not). If the volume has NOEXEC flag set, the syscall will fail with EPERM. However, this behavior is not observed when running under gVisor. Instead, gvisor allows this system call to be made without any issue. Thus this pull request aims to bring the same parity to gvisor implemented mmap syscall. FUTURE_COPYBARA_INTEGRATE_REVIEW=#11358 from Snowflake-Labs:xuzhoyin-mmap-fix 191b53d PiperOrigin-RevId: 720236462
copybara-service bot
pushed a commit
that referenced
this pull request
Jan 29, 2025
## Background This is Xuzhou (Joe) from `Snowflake Inc`. We are currently working on utilizing gVisor internally as our secured sandboxing mechanism. We have met in-person with gVisor team last October sharing our use case and experiences with the gVisor team. As part of the meeting, we (Snowflake team) committed to contribute our internal fixes/improvements back to the upstream. As part of compatibility testing with our previous mechanism, we found some behavior discrepancies between gVisor-emulated kernel and native linux kernel when making `mmap` system calls. Thus wanted to raise a pull request and see if this makes sense. ## Issue we observed On native linux kernel, when calling `mmap` syscall with PROT_EXEC on a file, linux kernel checks if the volume/file system backing the file is executable (ie. Has `NOEXEC` flag or not). If the volume has NOEXEC flag set, the syscall will fail with EPERM. However, this behavior is not observed when running under gVisor. Instead, gvisor allows this system call to be made without any issue. Thus this pull request aims to bring the same parity to gvisor implemented mmap syscall. FUTURE_COPYBARA_INTEGRATE_REVIEW=#11358 from Snowflake-Labs:xuzhoyin-mmap-fix 191b53d PiperOrigin-RevId: 720236462
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Background
This is Xuzhou (Joe) from
Snowflake Inc. We are currently working on utilizing gVisor internally as our secured sandboxing mechanism. We have met in-person with gVisor team last October sharing our use case and experiences with the gVisor team. As part of the meeting, we (Snowflake team) committed to contribute our internal fixes/improvements back to the upstream.As part of compatibility testing with our previous mechanism, we found some behavior discrepancies between gVisor-emulated kernel and native linux kernel when making
mmapsystem calls. Thus wanted to raise a pull request and see if this makes sense.Issue we observed
On native linux kernel, when calling
mmapsyscall with PROT_EXEC on a file, linux kernel checks if the volume/file system backing the file is executable (ie. HasNOEXECflag or not). If the volume has NOEXEC flag set, the syscall will fail with EPERM.However, this behavior is not observed when running under gVisor. Instead, gvisor allows this system call to be made without any issue.
Thus this pull request aims to bring the same parity to gvisor implemented mmap syscall.