On 2025-08-21, Askar Safin <safinaskar@xxxxxxxxxxxx> wrote: > There is one particular case when open_tree is more powerful than openat with O_PATH. open_tree supports AT_EMPTY_PATH, and openat supports nothing similar. > This means that we can convert normal O_RDONLY file descriptor to O_PATH descriptor using open_tree! I. e.: > rd = openat(AT_FDCWD, "/tmp/a", O_RDONLY, 0); // Regular file > open_tree(rd, "", AT_EMPTY_PATH); > You can achieve same effect using /proc: > rd = openat(AT_FDCWD, "/tmp/a", O_RDONLY, 0); // Regular file > snprintf(buf, sizeof(buf), "/proc/self/fd/%d", rd); > openat(AT_FDCWD, buf, O_PATH, 0); > But still I think this has security implications. This means that even if we deny access to /proc for container, it still is able to convert O_RDONLY > descriptors to O_PATH descriptors using open_tree. I. e. this is yet another thing to think about when creating sandboxes. > I know you delivered a talk about similar things a lot of time ago: https://lwn.net/Articles/934460/ . (I tested this.) O_RDONLY -> O_PATH is less of an issue than the other way around. There isn't much you can do with O_PATH that you can't do with a properly open file (by design you actually should have strictly less privileges but some operations are only really possible with O_PATH, but they're not security-critical in that way). I was working on a new patchset for resolving this issue (and adding O_EMPTYPATH support) late last year but other things fell on my plate and the design was quite difficult to get to a place where everyone agreed to it. The core issue is that we would need to block not just re-opening but also any operation that is a write (or read) in disguise, which kind of implies you need to have capabilities attached to file descriptors. This is already slightly shaky ground if you look at the history of projects like capsicum -- but also my impression was that just adding it to "file_permission" was not sufficient, you need to put it in "path_permission" which means we have to either bloat "struct path" or come up with some extended structure that you need to plumb through everywhere. But yes, this is a thing that is still on my list of things to do, but not in the immediate future. -- Aleksa Sarai Senior Software Engineer (Containers) SUSE Linux GmbH https://www.cyphar.com/
Attachment:
signature.asc
Description: PGP signature
