On 11/19/25 21:18, Aleksa Sarai wrote: > On 2025-11-19, Alyssa Ross wrote: >> Hello, >> >> As we know, it's not safe to use chroot() for resolving untrusted paths >> within some root, as a subdirectory could be moved outside of the >> process root while walking the path[1]. On the other hand, >> LOOKUP_BENEATH is supposed to be robust against this, and going by [2], >> it sounds like resolving with the mount namespace root as dirfd should >> also be. >> >> My question is: would resolving an untrusted path against a detached >> mount root dirfd opened with OPEN_TREE_CLONE (not necessarily a >> filesystem root) also be expected to be robust against traversal issues? >> i.e. can I rely on an untrusted path never resolving to a path that >> isn't under the mount root? > > No, if you hit an absolute symlink or use an absolute path it will > resolve to your current->fs->root (mount namespace root or chroot). > However, OPEN_TREE_CLONE will stop ".." from naively stepping out of the > detached bind-mount. If you are dealing with procfs then magic-links can > also jump out. Is using open_tree_attr() with MOUNT_ATTR_NOSYMFOLLOW enough to prevent these? Will it still provide protection even if someone concurrently renames one of the files out from under the root? I know that can escape a chroot, but I wonder if this provides more guarantees. https://github.com/QubesOS/qubes-secpack/blob/main/QSBs/qsb-014-2015.txt was the chroot breakout. > You can always use RESOLVE_BENEATH or RESOLVE_IN_ROOT in combination > with OPEN_TREE_CLONE. Unfortunately not everything supports that. For instance, mkdirat() doesn't. -- Sincerely, Demi Marie Obenour (she/her/hers)