Fix 2 — Writability fallback (lines 36-47)

[nicolasva]

reference : rails/rails#56997

Problem

In some containerized environments (Kubernetes with read-only root filesystem + emptyDir volumes), File.writable? (which uses the access(2) syscall) can return
false even though the directory is actually writable via mounted volumes.

Solution

Added a fallback to stat.writable? when File.writable? fails.

Changes

lib/tmpdir.rb:
when !File.writable?(dir)
# ... existing comment ...
#
# However, in some container environments (e.g. Kubernetes with read-only root filesystem
# and emptyDir volumes), File.writable? may return false even though the directory is
# actually writable via mounted volumes. Fall back to stat.writable? in that case.
if stat.writable?
warn "#{name}: File.writable? reports not writable but file mode bits suggest writable, using anyway: #{dir}"
break dir
end
warn "#{name} is not writable: #{dir}"

test/test_tmpdir.rb — 2 new tests:
Test: test_writable_fallback_to_stat
Description: Simulates a container environment where File.writable? returns false but stat.writable? returns true. Verifies the directory is accepted with a
warning.
────────────────────────────────────────
Test: test_writable_fallback_both_fail
Description: Verifies that a truly non-writable directory (chmod 0555) is properly rejected.
Test results

12 tests, 51 assertions, 100% passed

Fix 2 — Writability fallback (lines 36-47)

Ruby 3.4 changed stat.writable? to File.writable? (which calls the kernel's access(2) syscall). In some container environments, access(2) can return false even though the directory IS writable (due to security modules, mounted volumes, etc.). We now fall back to stat.writable? — if the mode bits say writable, we accept the directory with a warning.

Test added in [test/test_tmpdir.rb]: test_world_writable_allowed_by_env verifies that a 0777 directory without sticky bit is accepted when the env var is set.

Usage for K8s users
In the Dockerfile:

ENV RUBY_TMPDIR_ALLOW_WORLD_WRITABLE=1
Or in the Kubernetes deployment manifest:

env:
name: RUBY_TMPDIR_ALLOW_WORLD_WRITABLE
value: "1"

@rhenium this problem is describe here : rails/rails#56997

You're right, I'll split this into a separate PR.

To answer your question about when File.writable? (which uses access(2)) can return false even though the directory is actually writable:

This can occur in containerized environments with:

Kubernetes with read-only root filesystem + emptyDir volumes: The security context may restrict access checks at the syscall level, but the mounted volume is
still writable
SELinux/AppArmor policies: Security modules can affect access(2) results without actually blocking write operations
NFS mounts with root squashing or specific export options: As you mentioned, NFS can exhibit similar behavior
User namespaces in containers: UID mapping can cause access(2) to return incorrect results
The issue is that access(2) checks permissions based on the real UID/GID and may not account for all the kernel mechanisms that ultimately determine writability.
The actual open()/write() syscalls can succeed even when access() says no.

I don't have a specific reproducible environment to share right now, but I can try to create a minimal Kubernetes manifest that demonstrates this if that would
help. @rhenium