[Caveat: I don't hack the network stack. That said...] On Wed, 14 Aug 2013, Maxim Khitrov wrote: > That's exactly the behavior that I wanted. Here are some (untested) > examples:
Your examples obfuscated to me. If you want to limit it to stuff to/from this box, or not, SAY SO. (Yes: I think the whole 'unknown' handling by pf's user and group rules is a Bad Thing, as it confuses what's being matched.) > # Only match firewall-initiated connections > pass out proto tcp user >= 0 pass out proto tcp from self > # Only match connections where the firewall is the destination (and a > local daemon is listening) > pass in proto tcp user root pass in proto tcp to self user root > # Only match connections that will be forwarded (or nothing listening > on the local host) > pass in proto tcp user unknown pass in proto tcp to !self (Does this hit the optimizer issue?) > # Only match connections that were forwarded (similar to "received-on all"?) > pass out proto tcp user unknown pass out proto tcp from !self (Same question) > In my original example, the connection is forwarded, but "user root" is > either matched or ignored. I'm not sure which one, but either action is > wrong if the user is supposed to be "unknown" in this situation, as the > man page says. It explicitly states that such forwarded connections > should not be matched unless tested with "user = unknown". As suggested above: if I had my way, the whole 'unknown' thing would be removed and treated as a documentation bug. Figure out how to say what you _mean_ instead of hiding behind this indirection! Philip Guenther
