Allow bypassing world-writable sticky bit check in Dir.tmpdir for container environments

[nicolasva]

reference/issue : rails/rails#56997

We fixed two issues in [lib/tmpdir.rb]:

Fix 1 — Sticky bit check bypass (lines 48-58 and 128-132)

The existing check rejects any world-writable directory (0777) without the sticky bit. Kubernetes emptyDir volumes are mounted as 0777 without sticky bit by default. We now skip this check when:

Process.uid == 0 — root is not restricted by sticky bit on Linux anyway
ENV["RUBY_TMPDIR_ALLOW_WORLD_WRITABLE"] is set to 1, true, or yes
This applies to both Dir.tmpdir and the parent directory check in Dir.mktmpdir.

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 looks like two separate changes and should be split into two PRs.

Fix 1 — Sticky bit check bypass (lines 48-58 and 128-132)

I don't have an opinion on whether it should be configurable, but the current behavior appears to date back to Ruby 2.0.0 released in 2013: 6dbb585

Fix 2 — Writability fallback (lines 36-47)

/cc @KJTsanaktsidis

This is basically a revert of 47eeddd, which was merged to tmpdir v0.3.0 and is bundled with Ruby 3.4.

In some container environments, access(2) can return false even though the directory IS writable (due to security modules, mounted volumes, etc.).

Could you elaborate more on the environment where this occurs? I think I've seen a similar situation in the past with an NFS mount on Linux (not related to tmpdir or Ruby). Unfortunately, I can't reproduce it anymore and don't know what caused it for me.

[nicolasva]

@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