[Hixon10]

What would be an use case for `os.Root`? Based on my understanding ( https://github.com/golang/go/issues/67002 ), it is related to security. However, under the hood, it doesn't use `Chroot`, so I could imagine, that eventually someone finds a way to escape from the Root.

[duskwuff]

chroot only makes sense for applications which can commit to exclusively operating out of a single directory, ever. (It also requires the process to have superuser privileges, so it can't be used by applications which are run as users.)

os.Root() is more about putting a "seatbelt" on filesystem operations - like restricting operations related to an application's cache to its cache directory, or restricting a file server to serving files from the appropriate shared directory. It's not the same kind of ironclad guarantee as chroot, but it'll still protect an application from simple directory traversals.

[fweimer]

Linux has had unprivileged chroot for a while, via user namespaces. Their setup is a bit complicated if you want to support nesting in other container runtimes: https://sourceware.org/git/?p=glibc.git;a=blob;f=support/sup...

After this dance, you can call chroot from within the new namespace. It's often also possible to use unprivileged bind-mount /dev, /sys, /proc, for a more regular execution environment (although some container runtimes block this unfortunately).

[demi56]

Yeah, some dev usually don’t put safe guards especially when the user input is directly linked to file operations

[Hixon10]

Yeah, I like your examples. In such scenarios, it makes sense when we're just trying to protect against our own bugs rather than a user deliberately sending a path that leads to the password.txt file.

[nesarkvechnep]

Why would it use `chroot`? Combined with a sandboxing facility, like Capsicum, you can open a directory before entering capability mode and later, you use `os.Root` to open files in the file system tree under the opened directory.

[Hixon10]

> Why would it use `chroot`?

I am not sure, is this custom Os.Root implementation good enough to relay on it? I see that it is based on openat, and validation of paths/symlinks. But should we expect CVEs, which will break this protection layer?