{"id":183605,"date":"2026-10-05T10:54:21","date_gmt":"2026-10-05T08:54:21","guid":{"rendered":"https:\/\/prohoster.info\/blog\/news\/teo-de-raadt-predlozhil-izmeneniya-dlya-ogranicheniya-dostupa-k-fs-cherez-funkcziyu-openat"},"modified":"2026-10-05T10:54:25","modified_gmt":"2026-10-05T08:54:25","slug":"theo-de-raadt-proposed-changes-to-restrict-filesystem-access-via-openat","status":"publish","type":"post","link":"https:\/\/prohoster.info\/en\/blog\/news\/theo-de-raadt-proposed-changes-to-restrict-filesystem-access-via-openat","title":{"rendered":"Theo de Raadt proposed changes to restrict access to the filesystem through the openat function.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Theo de Raadt proposed to include a new mechanism in OpenBSD to reduce the attack surface, implemented through the enhancement of the openat system call. Patches implementing additional flags for openat and open, which limit the ability to traverse to parent directories via \"\/..\" and access by absolute paths, are prepared for the kernel, libc, as well as some base system applications. The changes are not yet included in OpenBSD-current and are under discussion among developers. <\/p>\n
The family of system calls openat(2) works as an analog to open(2) except that if a relative path is specified in the \"path\" parameter, the file being opened is determined relative to the directory associated with the file descriptor \"fd\" rather than the current working directory. If an absolute path is passed to openat, for example: int dirfd = open(\"\/tmp\", O_RDONLY | O_DIRECTORY); int hfd = openat(dirfd, \"etc\/hosts\", O_RDONLY); <\/p>\n
the openat() function will ignore \"dirfd\" and consequently, the absolute path will be processed in the usual manner. <\/p>\n
Therefore, replacing open() with openat() does not, by itself, enhance the security of the program. Such a call may speed up path parsing, but does not restrict access to the file system. The flags that prevent absolute paths (such as RESOLVE_BENEATH and\/or RESOLVE_IN_ROOT for openat2 in Linux) do not guarantee protection: the programmer must add them to all appropriate calls, and if the control of the process is compromised, an attacker may exploit other file-opening paths. <\/p>\n
During the development of the openrsync utility, Theo faced the necessity to limit its filesystem traversal capabilities, but it was not feasible to do this with the unveil() and pledge() functions. This led to the idea of a mechanism similar to openat(), but with security properties that complement pledge\/unveil or even operate in their absence. <\/p>\n
The main idea is to make the restrictions part of the directory descriptor itself. To achieve this, a flag F_BELOW is proposed, which can be set via fcntl(), or the flag O_BELOW for open(). A descriptor \"dirfd\" restricted in this way will only allow downward traversals in the directory tree: calls to openat() with an absolute path or upward traversals via \"..\" will return an error ENOENT. In the case of an attack leading to code execution, the process's file descriptor table will contain less functional \"dirfd\", which will limit the attack surface. \n Source: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"