3 ms·
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 superu
by duskwuff 2y ago
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.
- Hixon10 2y agoYeah, 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.
- demi56 2y agoYeah, some dev usually don’t put safe guards especially when the user input is directly linked to file operations
- fweimer 2y agoLinux 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/support_become_root.c 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).