[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: PF in 3.3-current, ioctl
after you call DIOCCHANGERULE with PF_CHANGE_GET_TICKET - does
DIOCCHANGERULE return anything for the rules it accepts?
I'm just starting to read up on this - pardon my guessings
> 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
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.