[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.