- The NAME_MAX check in VFS.RenameAt() was added in cl/464173793. The
motivations cited by that CL were (1) consistency with
fs/namei.c:do_renameat2() => getname() and (2) ensuring that no implementation
of FilesystemImpl.RenameAt() would create a file that
FilesystemImpl.SetXattrAt() would fail on, resulting in inconsistency in
overlay.filesystem.RenameAt(). However, getname() enforces a maximum length of
PATH_MAX (which we enforce in sentry/syscalls/linux/path.go:copyInPath()), not
NAME_MAX, and no check on the old name is needed to satisfy property (2).
- The NAME_MAX limit in fsutil.ParseDirents() is unnecessary.
Updates #12441
PiperOrigin-RevId: 853425050
- Added `fsutil.ForEachDirent()` (used by directfs).
- Added `fsutil.DirentNames()`, which uses `ForEachDirent()`. Used by sysfs
and in the future will be used by nvproxy/tpuproxy.
Separately, fixed some bugs in sysfs:
- We were leaking FDs in `hostDirEntries()`.
- We were leaking FD in `hostFile.Generate()` on error path.
- Got rid of `hostFileBufSize` users. They expected contents to be of 4096
bytes only. Instead made the functions agnostic of file size.
PiperOrigin-RevId: 580688250
We can achieve this by opening the current working directory for the sandbox
process right before the application starts. We use this cached FD to restore
CWD after DoInDir() operations.
Since the package which provides DoInDir() has to be aware of the sandbox
process and requirements around initializing the CWD, I have moved this to
pkg/sentry/fsutil - which can contain sentry aware code.
This will be used by directfs. This helps because this allows us to block
AT_FDCWD in directfs seccomp filters.
PiperOrigin-RevId: 513409592
Directfs accesses host filesystem directly, without going through the gofer
server. This change basically adds runsc fsgofer functionality into the gofer
client. We use the gofer dentry impl abstraction to make direct host syscalls
instead of making LISAFS RPCs. It works on a donated FD to the root of the
mount. All other relevant mount options supported in gofer client are also
supported here.
Directfs is also a lisafs user. Directfs client makes a Mount RPC. The server
is expected to donate a host FD to the mount point that the client can use to
perform all necessary filesystem operations. Directfs client does not set up
any flipcall channels, because it (mostly) doesn't make any RPCs.
Note however that we can not avoid LISAFS RPCs in certain cases. Certain
operations like bind(2) and connect(2) require host paths. But the container
filesystem is not mounted inside the sandbox's mount namespace. The sandbox
just has an FD to the filesystem root. Furthermore, procfs is also not mounted
in the sandbox process for security reasons. Otherwise we could have used host
paths like `/proc/self/fd/<sockFD>`. The only viable option is to use fchdir(2)
to change working directory to the socket's parent directory and use a relative
host path from there. But in certain situations, we don't even have access to
a socket's parent directory (in case of a socket mount point). The parent lives
in a different gofer mount in the sentry. There is no clean way of fetching
that. In these extreme corner cases, directfs falls back to using LISAFS RPCs.
These corner cases are:
- chmod(2) on mount point socket.
- utimensat(2) on mount point symlink.
- connect(2) on mount point socket.
PiperOrigin-RevId: 510465837
