On Wed 22 Feb 2023 at 18:12:29 (+0100), [email protected] 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.
