Open BinaryKhaos opened 2 weeks ago
gVisor doesn't support O_TMPFILE yet: https://github.com/google/gvisor/blob/3c4b2ad07ce1b830bbfa00b3fdcb7dca0d95782a/pkg/sentry/fsimpl/gofer/filesystem.go#L928-L934 https://github.com/google/gvisor/blob/3c4b2ad07ce1b830bbfa00b3fdcb7dca0d95782a/pkg/sentry/fsimpl/tmpfs/filesystem.go#L340-L343 https://github.com/google/gvisor/blob/3c4b2ad07ce1b830bbfa00b3fdcb7dca0d95782a/pkg/sentry/fsimpl/erofs/filesystem.go#L220-L222
@BinaryKhaos Just curious, in your "pam_oath on openSUSE Tumbleweed" use-case, does the application use O_TMPFILE on /tmp
directory (or one of its subdirectories)? I am wondering if we could just add O_TMPFILE support to gVisor tmpfs and unblock you. Support for it in gofer is a bit more involved, but tmpfs should be doable.
@ayushr2 Unfortunately not. It's used in the same (configurable) directory where a specific configuration file is located... usually somewhere in /etc
or /home
. You can find the patch (and the rest of the code) here, if that helps.
Description
The following fails with runsc but succeeds w/ crun/runc as well as on the host:
This is a very reduced testcase for a failure I am seeing w/ the latest pam_oath on openSUSE Tumbleweed in a container where they applied their own patch (which introduces this behaviour) in order to fix a CVE (different from upstream).
Steps to reproduce
runsc version
runsc version release-20241028.0-23-gbcbb6a01e13b-dirty spec: 1.1.0-rc.1
docker version (if using docker)
host: arch: amd64 buildahVersion: 1.37.5 cgroupControllers:
uname
Linux TARDIS 6.11.5-gentoo-241023-r1 #1 SMP PREEMPT_DYNAMIC Wed Oct 23 17:53:43 CEST 2024 x86_64 Intel(R) Core(TM) i7-6700K CPU @ 4.00GHz GenuineIntel GNU/Linux
kubectl (if using Kubernetes)
No response
repo state (if built from source)
No response
runsc debug logs (if available)
No response