Re: PR 291981: authpf under netlink, and a pfctl adoption flag
Date: Fri, 24 Jul 2026 15:17:37 UTC
On 24 Jul 2026, at 5:32, Avinash Duduskar wrote: > From: Avinash H. Duduskar <avinash.duduskar@gmail.com> > > Hi all, > > Kristof asked me to bring this here from a private thread; it is a > design question about authpf under the pf netlink conversion, and a > small fix. > > authpf breaks on 15.x (PR 291981) at the exec. change_filter hands the > child the root /dev/pf fd as -p /dev/fd/N, so its ioctls still work; but > that flag carries only the device fd, and pfctl's first privileged > netlink command (PFNL_CMD_BEGIN_ADDRS, since ba2a9207862) rides a fresh > socket it opens after the setresuid drop, so the kernel's per-command > check sees the dropped cred and EPERMs. Nobody authenticates. The > DIOCBEGINADDRS in the report is a stale label; the call is netlink now. > Okay, so I did not understand this at all, because surely authpf only calls pfctl_open() once, and it does it before it drops privs. Then I took a closer look at change_filter(), and now I wish I hadn’t. No. We’re not doing that. We’re not forking a pfctl instance to do the work for us. Just no. Let’s not double down on the horror. The way to fix this is to just call libpftl from change_filter(), not this mess with pfctl and remapped fds. It can still drop privs or capsicumise or whatever if it wants to, but if it calls libpfctl to do the work it’ll be much faster, much cleaner and it can just use the handle we opened when we still could. If libpfctl is missing functions I’ll happily add them, but we’re not doubling down on the wrong way. — Kristof