https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=289234
--- Comment #2 from [email protected] --- (In reply to Kristof Provost from comment #1) > I suspect you're mis-identifying the problem. It's not that you're running in That's possible. > a jail (which works just fine, because that's how the pf tests work), but > that you're not running as root. (Or to be pedantic, which we all enjoy, > as a user without the NETINET_PF privilege.) So, if I understand you right, the change to netlink in pf( creates the need of the NETINET_PF privilege for the user of pfctl. As user 0 in a jail does not have this privilege (of cause) the results are what I reported. I found it very convenient to change the devfs ruleset of a jail to be able to change the pf rules as user 0 from inside a jail (e.g. blacklistd) and also have other jail users restricted by the mode /dev/pf has. > I'm not quite sure what the best way forward is, in that regard. I'm inclined > to say users should grant the NETINET_PF privilege to any account they want > to give pf access to. Perhaps we should also introduce NETINET_PF_RO > (i.e. read-only) for the read calls, so that it's possible to allow read > access without giving full firewall access. May be I searched for the wrong keywords because I did not find a way to give a jail (0 user) the NETINET_PF privilege, so this idea can be totally in the wrong direction: Extending the jail allow parameters by allow.pf which sets the NETINET_PF privilege. So user 0 in such a jail can operate on pf while the mode of /dev/pf inside the jail stops other users (in the jail) from doing so. This would restore the former ioctl behavior without opening the access to pf too much as one has still to change jails devfs_ruleset too. Ralf -- You are receiving this mail because: You are the assignee for the bug.
