The use case is isolation, which is not necessarily exactly the same as reducing access.
For example, maybe you don't want the process to be able to easily detect that it has had its access reduced, by simulating a full-access environment.
Or for example, maybe you don't care about access at all and you just want to avoid conflicts between two processes by giving them separated namespaces for their data.
Can you elaborate on this please? I'd consider unveil to be far more capable of creating "an arbitrarily structured virtualized filesystem" view than chroot. I'd also invert the thinking of "just hide parts of the existing filesystem" as it whitelists paths and access rather than blacklisting.
Chroot is more or less a bind mount over /. Bind mounts generalize chroot. Unveil does not, and therefore does not allow you to provide arbitrary views of the file system.
It's useful for other reasons. On OpenBSD, a full web browser compromise does not lead to full file system access.
Unveil has no way to change the existing structure of the filesystem. With chroot it's easy: create the structure you want in a subdirectory and then chroot into it
If changing a process root directory is really what you want to do then yes chroot is the right tool for the job. But from a perspective of "jailing" daemons as mentioned in the article I think unveil is a better API.
I'm not sure what pieces of software populate directories and then chroot into them aside from maybe some build systems? But those likely create or bind in some /dev and /proc pieces which would be privileged operations anyway. And in such a case would containers not have surplanted chroot?
"Jailing" isn't necessarily just about security, but isolation in general. Unveil would be a stronger tool if the concern is strictly security, but also there's no reason they couldn't both be used.
Chroot is itself sometimes used to provide container-style functionality, so I think it's wrong to say containers "surplanted" it.
