- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
May 21 2024
In D45231#1032684, @wosch wrote:Are you able to follow this up? I'm still unsure when a PR is better than a review, so sorry if I've messed up protocol.
I recycled an old PR 275978, no need to open a new one. I consider the issue as resolved with 37be4197f72ae3a61bd5e93d2ebdc9bd6d09ed21
Correct typo
I think this is fine, if we have problems we can amend it
In D32306#1032991, @kevans wrote:I could throw something in src/UPDATING to mention it?
In D45196#1031264, @jhibbits wrote:Given that all(?) other ethernet drivers unconditionally ETHER_BPF_MTAP() (so, ether_bpf_mtap_if())
In D32306#1032957, @saper_saper.info wrote:Related, mostly about documenting this: https://lists.freebsd.org/archives/freebsd-current/2024-May/005969.html
May 20 2024
Content-wise, it looks good to me now.
@trasz : thanks for sending this review request. My general feeling is that I'm leery of relaxing the in-kernel security model, not just because of the potential for opening things we don't mean to open, but also because it complicates the model for those who are trying to understand it. "No global namespaces", while limiting, is a clearer rule than "no global namespaces unless you or your ancestor has previously called fchroot(2), unless-unless something has also called cap_enter(2) again to clear that magic vnode".
Related, mostly about documenting this: https://lists.freebsd.org/archives/freebsd-current/2024-May/005969.html
Remove too aggressive assert.