I'm making a status monitor for things like battery, time, etc. to use
with dwm. I wanted to use pledge(2) and unveil(2) to lock things down as
well as to help me learn C.
The first issue I came up against was with pledge and apm(4). The
ioctl(2) calls used to retrieve power state do not appear to be one of
the supported promises from pledge. I looked at the source for apm(8) to
discover that after getting the power state it restricts itself to the
stdio promise. As the status monitor needs on-going power information it
does not seem like a good fit to use pledge at this time.
I applied unveil next. This went much more smoothly allowing only the
few files required for the programme to function. However, I've realised
since that I only need to access a few files at initialisation and then
I can shut off all access to the file system.
>From the man page on unveil(2):
> After establishing a collection of path and permissions rules, future
> calls to unveil can be disabled by passing two NULL arguments.
i.e. you must do at least ONE successful call to unveil before you can
lock the rest of the file system. This means unveil must be used on
a location that exists on the file system. As a workaround, you can
almost block access to the file system with something like
unveil("/dev/null", "r"). However, I would have expected
unveil(NULL, NULL) on its own would have been enough.
Have I missed something trying to use pledge(2) and unveil(2)?
P.S. Any tips for debugging programmes that exit from these
technologies? I've been running ktrace(1)/kdump(1) and sort of bumbling
through the output which seems to work okay.
--
Chris Rawnsley
