Re: Debugging what is deleting/recreating /etc/resolv.conf with wrong configuration, on debian stable
On Wed 22 Feb 2023 at 18:12:29 (+0100), davenull@tuxfamily.org wrote:
> What I want is: setting up /etc/resolv.conf ONLY
> - at system startup/initial network connexion.
> - when openconnect is executed and connects to work's VPN
> - when openconnect is ^C-ed and disconnects from the works VPN
> (cleaning it's mess in the routing table, interfaces, /etc/resolv's
> and other netwwork stuff it might have modified, makes sense)
What's the output from ls -l /etc/resolv.conf
What's responsible for restoring the previous contents of
/etc/resolv.conf to your normal network connection when you
finish "work" and tear down the VPN.
> - I don't use systemd-resolvd. My OS image (Debian stable, LXDE,
> connmann as the default network manager) ships with systemd-resolvd
> disabled and I'm totally OK with it
> - I do use connmann and didn't replace it with anything else
> - The process that deletes and recreates /etc/resolv.conf runs as
> root. I used auditd to detect when changes that file… but I can't a
> get any process name. I can just see it's root
One way of finding the process is to # chattr +i /etc/resolv.conf
while you're "at work", so that you get permission errors in the
logs when it happens. (Remember to chattr -i before you "stop work".)
But how do you manage /etc/resolv.conf with connman. I don't use it,
but I read there's a plug-in for that. Is openconnect correctly
informing connman when it finishes.
> I was expecting to see a process name it the audit.log file BUT it
> didn't happened so I'm still stuck. so my question is: How to debug
> that further, and identify the exact process that screw up with
> /etc/resolv.conf file… So from there I could search for a way to
> prevent that by modifying the rights config file or whatever…
Whatever the "rogue process" is should be informing whatever the
"/etc/resolv.conf controller" is, shouldn't it, rather than being
blocked. (It might be legitimate rather than "rogue".)
Cheers,
David.
Reply to: