Hi Thomas, Hi Chris, On Fri, May 02, 2025 at 11:47:24AM +0200, Thomas Liske wrote: > I wonder why needrestart selects this service at all. Could you provide the > output of `needrestart -v` for this?
Unfortunately we already restarted all the affected nodes. Do you want me
to try and recreate the problem in debvm?
> > I think we should add an exception for nftables to $nrconf{override_rc} to
> > avoid this problem since there doesn't seem to be any point in restarting
> > it for security purposes.
>
> ACK, IMHO it should be completely ignored and one should consider the same
> for iptables. But I still wonder why the service gets selected at all…
My assumption: because the executable changed due to the migration of
1.1.2-1 to testing on 04-26. We saw the nftables service was restarted on
affected nodes on 04-27 at about 6am i.e. almost certainly because of
unattended-upgrades.
Why do you think it should be ignored already?
On Fri, May 02, 2025 at 11:50:20AM +0200, Chris Hofstaedtler wrote:
> On Fri, May 02, 2025 at 11:37:04AM +0200, Daniel Gröber wrote:
> > Justification: Breaks unrelated software
> (IMO needrestart is not "unrelated" here.)
I do think the severity is justified, nftables is the "unrelated" software
needrestart is breaking. See
https://release.debian.org/trixie/rc_policy.txt first section:
>> * makes unrelated software on the system (or the whole system)
>> break
> Isn't this really a bug in nftables and maybe lxc? If restarting a
> service wipes its configuration, maybe it should be fixed there.
I did consider that. Unfortunately too much networking software is already
doing things this way to my knowledge and personal dismay. Think: docker,
libvirt etc.
I think nftables should support a .d directory to fix this "properly".
However since most upstream sofware treats the firwall as runtime state
there's going to be an impedance mismatch if we just stick this in
/etc/nftables.d.
So really we'd have to also support /run/nftables.d to allow representing
the intended semantics and I'm personally just not convinced that's the
right thing to do yet since I haven't thought of this runtime-state
consideration before.
For now adding an exception for nftables fixes the immediate issue and
doesn't have any downsides I can see and I'll carry the .d thing forward in
any case -- now with a good example issue for why it's needed :-)
Thanks,
--Daniel
signature.asc
Description: PGP signature
