On Wed, Mar 12, 2003 at 05:00:48PM +0100, Marc Balmer wrote: > Is it correct that DIOCCHANGERULE now needs a ticket for every operation > (in earlier releases I didn't need a ticket for adding a rule at the tail)?
Yes, that was introduced a couple of weeks ago. > Is this a one time ticket or do I need some sort of "commit" ioctl call? Your example is right, you first call DIOCCHANGERULE with PF_CHANGE_GET_TICKET, then you can use that ticket for any number of DIOCCHANGERULE calls (with PF_CHANGE_ADD_TAIL or other actions). The next time some process fetches a ticket, your old one expires and further usage results in an EINVAL ioctl error. So, you might want to fetch a ticket before each change, if changes are done sporadically, or handle the EINVAL error by fetching a new ticket and retrying. > Is there an ioctl which informs me of "third party" rule changes? I.e. > a possibility to register a callback which gets called when something > else changes a rule? There's no such ioctl yet. You can put your managed rules into an anchor, so your daemon is the only part modifying that subruleset. Check the -current pf.conf(5) man page about anchors. I don't know how to implement a real callback (in the sense that the kernel would actively signal a change to a userland process), but we could add (post-3.3 :) some counter in rulesets which get increased whenever a rule inside that set is changed, so a userland daemon could poll that counter actively and detect changes (through ioctl). Take a look at -current authpf, it's now using its own anchor for the rules it manages, and doesn't have to deal with concurrent changes from other processes, it gets much simpler when a daemon can just flush and reload an anchor instead of adding/removing single rules from head/tail. Daniel
