Fix 2 — Writability fallback (lines 36-47)

[nicolasva]

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.

See rails/rails#56997 for more context.

Changes

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

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. ifstat.writable?warn"#{name}: File.writable? reports not writable but file mode bits suggest writable, using anyway: #{dir}"breakdirendwarn"#{name} is not writable: #{dir}"

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.

Usage for K8s users

This can occur in containerized environments with:

env:
name: RUBY_TMPDIR_ALLOW_WORLD_WRITABLE
value: "1"

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

[Copilot]

Pull request overview

This PR adjusts Dir.tmpdir selection to better handle containerized environments where File.writable? (access(2)) can report a false negative, by adding a fallback acceptance path based on stat.writable?, and adds tests covering the new behavior.

Changes:

• Add a fallback in Dir.tmpdir to accept a candidate directory when File.writable? is false but stat.writable? indicates it should be writable, emitting a warning.
• Add tests for (1) the fallback acceptance-with-warning path and (2) the rejection path when both checks indicate non-writable.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File	Description
lib/tmpdir.rb	Adds the new “writability fallback” behavior and warning during tmpdir candidate selection.
test/test_tmpdir.rb	Adds regression tests to validate the fallback and non-writable rejection behavior.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[ioquatix]

I tested this with a local Kubernetes cluster (kind v1.36.1 node image) using Ruby 3.4.8 and a pod with readOnlyRootFilesystem: true plus emptyDir mounted at /tmp.

For default disk-backed emptyDir mounted at /tmp, the probe showed:

{uid: 1000,euid: 1000,mode: "40777",writable: true,stat_writable: true,sticky: false,world: 511,write: true}

So in the reproduced Kubernetes case:

• File.writable?("/tmp") is already true
• File.stat("/tmp").writable? is also true
• actual writes succeed
• the directory is rejected because it is world-writable without the sticky bit (0777, not 01777)

Stock Dir.tmpdir then fails with:

TMPDIR is world-writable: /tmp
system temporary path is world-writable: /tmp
/tmp is world-writable: /tmp
. is not writable: /
ArgumentError: could not find a temporary directory

I also tested emptyDir.medium: Memory, which mounted as sticky and worked:

{tmpdir: "/tmp",mode: "41777",sticky: true}

This suggests the Kubernetes/Rails issue is a sticky-bit problem, not a File.writable? false-negative problem. The linked Kubernetes PR (kubernetes/kubernetes#130277) matches that: it adds sticky-bit support for emptyDir so it can be mounted as 01777.

I also tested a read-only root filesystem without a writable /tmp mount. In that case:

File.writable?("/tmp")# falseFile.stat("/tmp").writable?# trueFile.write("/tmp/probe","x")# Errno::EROFS

With this PR's fallback, Dir.tmpdir would accept /tmp in that case even though actual writes fail. So the fallback from File.writable? to stat.writable? appears risky and does not address the reproduced Kubernetes emptyDir failure.

Based on this, I think the correct fix is Kubernetes/pod configuration setting the sticky bit (01777) on the temp directory, rather than changing Ruby to trust stat.writable? when File.writable? says no.

[ioquatix]

As a temporary application-level workaround until Kubernetes can mount disk-backed emptyDir with the sticky bit set, users could opt into a narrow monkey patch rather than changing Ruby's default behavior globally.

For example, in an app boot file that runs early:

require"tmpdir"classDirclass << selfalias_method:tmpdir_without_kubernetes_emptydir_workaround,:tmpdirdeftmpdirtmpdir_without_kubernetes_emptydir_workaroundrescueArgumentErrordir=ENV["RUBY_TMPDIR_ALLOW_UNSAFE_EMPTYDIR"]raiseunlessdir && !dir.empty?dir=File.expand_path(dir)stat=File.stat(dir)raiseunlessstat.directory?raiseunlessFile.writable?(dir)path=File.join(dir,".ruby-tmpdir-check-#{Process.pid}")File.open(path,File::WRONLY | File::CREAT | File::EXCL,0600){}File.unlink(path)warn"Using world-writable non-sticky tmpdir due to RUBY_TMPDIR_ALLOW_UNSAFE_EMPTYDIR=#{dir}: #{dir}"direndendend

Then configure the pod explicitly:

env:
- name: TMPDIRvalue: /tmp
- name: RUBY_TMPDIR_ALLOW_UNSAFE_EMPTYDIRvalue: /tmp

This intentionally bypasses Ruby's sticky-bit safety check, so it should only be used in tightly controlled containers where the temp directory is not shared with untrusted users/processes. It also uses a real write probe, not stat.writable?, so it will not accept a read-only-root /tmp where mode bits say writable but actual writes fail.

Preferred fixes remain: mount a temp directory with mode 01777, use emptyDir.medium: Memory where appropriate, run an init container to chmod 1777 the mounted emptyDir, or use Kubernetes sticky-bit support once available.