• Contributor and Date: Contributed by Peter N. M. Hansteen on 2025-05-28.
• Problem with File System Access: Reining in file system access is difficult even for [OpenBSD] developers. Theo de Raadt describes in a message to tech@ titled openat(2) is mostly useless, sadly how the [openat(2)](https://man.openbsd.org/openat.2#openat) family of system calls fails to meet expectations in practice and proposes changes.
• Details of the Problem: The system calls related to openat(2) are rarely used and often ineffective or have performance-reducing results. For example, openat(herefd, "/etc/passwd, O\_RDONLY) will open the file ignoring herefd, and relative paths upwards like "../../../../something" will walk up the path and open it. These calls were not designed to assist security models.
• Theo's Proposal: Create directory fd's that cannot traverse upwards. Mark the object with two operational flags, O\_BELOW and F\_BELOW. Use dirfd = open("path", O\_DIRECTORY | O\_BELOW) or fcntl(dirfd, F\_BELOW) to create a locked directory fd. Absolute accesses fail with ENOENT and relative accesses upwards fail. Code using readdir() must be careful as operations on ".." will fail.
• Interesting Use Case: This is like a chroot() system call for non-root users. You can dirfd = open("path", O\_DIRECTORY | O\_BELOW); fchdir(dirfd); to contain the process inside the directory. Absolute path accesses with open() start at the process current directory and fail. This has not been extensively explored yet.
• Conclusion and Call for Feedback: This is just a draft. The main idea is to improve pathname containment in the kernel. It can work with unveil() and is cheaper as the kernel doesn't need to hold references to vnodes. Testing and feedback are welcome. Theo de Raadt followed up with a message adding a regression test on 2025-05-30 and some discussion is in progress. The diff is against a very recent -current.