Add comprehensive overlayfs copy-up test suite to gVisor
- Dominant language
- Go
- Stars
- 19.3k
- Forks
- 2k
- Avg merge
- 3d 5h
- Merged PRs (30d)
- 264
Description
### Description
### Problem / Missing Coverage
Currently, gVisor's open-source test suite (`test/syscalls` / `test/e2e`) lacks comprehensive tests for **overlayfs copy-up behaviors and edge cases**. The only existing test is a basic container integration test (`images/basic/integrationtest/test_copy_up.c`) covering `open(O_RDWR)` and `mmap` on regular files.
Important edge cases in overlayfs copy-up are currently untested in the repository, including:
1. **Non-copy-upable lower files (FIFOs / Sockets)**: Verifying that `open(O_WRONLY)` or `access(..., W_OK)` on lower-layer FIFOs/sockets that cannot be copied up fail cleanly with `EPERM` / `EACCES` rather than hanging or attempting invalid copy-up operations.
2. **Copy-up triggers**: Operations like `truncate`, `chmod`, `chown`, `utimes`, `link`, `symlink`, `mknod`, and `mkdir` on lower-layer dentries.
3. **Permission checks**: Ensuring read-only files (`0444`) on lower layers do not get copied up when `O_RDWR` open attempts fail with `EACCES`.
4. **Special files on read-only mounts / overlayfs**: Verifying that character devices (`/dev/null`) and pipes behave correctly across overlay layers and read-only mounts.
### Proposed Solution
Add a dedicated `CopyUpTest` test suite to gVisor's test suite (under `test/syscalls` or `test/e2e`) to cover these overlayfs copy-up scenarios.
- Prevents regressions in overlayfs copy-up handling (e.g., deadlocks/hangs when opening lower FIFOs for write access or incorrect mount/copy-up permissions).
- Ensures consistent behavior between gVisor overlayfs implementation and native Linux kernel overlayfs.
### Is this feature related to a specific bug?
_No response_
### Do you have a specific solution in mind?
_No response_
Contributor guide
Assessment
This issue has not been assessed yet.