[tetromino_]

For example, the hypothetical language could require you to declare that a block of code is allowed to write only within a certain filesystem path (or list of paths). Attempts to escape from the path prefix - e.g. using /../ - would be caught by the compiler for static paths; and non-static strings representing paths would be required by the language's type system to be passed through a specific validator before they can be used for filesystem access.

[wahern]

Symlinks mean that you cannot simply validate the path string. You need to iteratively walk the path using openat(2) to avoid TOCTTOU bugs. But iteratively walking the tree with openat makes it tricky to tell if you've left the containing directory, especially if you dereference symlinks (disallowing them would be easier). This sort of thing is better handled in the kernel; or rather, whatever code is resolving and creating the resource handle in the first instance.

Unix chroot provides precisely the behavior desired here; unfortunately it requires root privileges.

Capsicum introduced the O_BENEATH flag to the openat(2) system call. openat(somedirfd, path, O_BENEATH) will fail if the path references a file above somedirfd. Unfortunately I don't think it has yet made it into Linux or FreeBSD, no doubt because the semantics are trickier than you'd think (there are very good reasons why chroot is limited to root, so you can't simply reuse the chroot infrastructure). See https://lwn.net/Articles/619146/ and https://reviews.freebsd.org/D2808 and http://capsicum-linux.org/