Everything you currently consider missing is available. Because I used them all.
- The abort from a policy violation produces a .core file. A backtrace will point you immediately to both the failing system call, and to the calling path from the application. This addresses all four of your concerns, and was my key development tool.
- A failed pledge() call will take the code path desired by the author. That can be as simple as a call to perror(3), but the pledge author can cause any operation they write. This is instrumentation by definition, and may include one, two or all three of your remaining concerns.
- System calls may be traced and monitored with ktrace(1)/kdump(1). Theo has mentioned on misc@ that this is they key tool for pledge() implementation, but I found item 1 above more useful. Probably because for me this is only instrumentation and records, requires separate analysis and doesn't include feedback.
- Because the application I pledged has such complex underpinnings, I used my own debug preprocessor tokens during development and testing. And when unexpected code paths were taken and discovered long after testing had completed, they were useful to me again. An example of the added debug token use with pledge can be seen in this patch. This is instrumentation, reporting, and feedback -- three out of four, but permitted me much simpler analysis.
Some applications are not really pledge-able. I just looked at sysutils/shunt, which has three utility programs. The
exactly program is easy to pledge. It only needs
stdio, and the pledge() can be placed as the first instruction in main(). Tested, works fine. But the
shunt program? It issues fork()/execlp() sequences of a user-specified program. These child processes are outside the control of the shunt program. They are typically going to be shell scripts, or direct calls to
cdrecord or
growisofs. I'm unsure if pledging a program like
shunt would add value. It might, because ksh(1) has been pledged. But there are plenty of shells which have not been pledged yet, and neither sysutils/cdrtools nor sysutils/dvd+rw-tools have been pledged to date.