Bryan Steele <[email protected]> wrote: > The privileged part of pflogd(8) is now disallowed from accessing most > of the filesystem, veiled except for read-only opening of /dev/bpf, and > rwc for the log file, typically /var/log/pflog. This process cannot yet > pledge(2), so special care is needed to make sure no library functions > called use files permitted by certain pledges.
I'd like to bring attention to this last sentence, and explain it better. unveil and pledge have much in common behaviourwise, but there is a a subtle difference to keep in mind. pledge is a fail-closed technology. If you do a system call (or subset of a system call) which is not permitted, you get killed. unveil isn't the same, it provides fail-closed behaviour for the filesystem objects, but that means it returns an error which is really fail-open behaviour for the program. Meaning, if you access a file which is not permitted, it will not exist. An error is returned for the application code to handle. Now take a moment to consider code in programs (or more specifically -- in libraries). If a file doesn't exist, many cases simply carry on. A detail they were trying to learn from that file isn't known to the program, but it carries on best-effort. The program continues on working, except for that subset of functionality is now broken.. This happened with the unveil of un-pledged ifconfig. The /etc/hosts file wasn't in view. Normally pledge "dns" would whitelist that file, but we cannot use pledge in ifconfig due to the vast range of ioctl requests. Therefore, /etc/hosts was "disappeared". Functionality of ifconfig was broken somewhat silently, and it took a few days to notice it and repair it, by explicitly whitelisting the required files. So please be more careful with unveil -- you don't get a nice crash. You have to understand the program's needs.
