1 |
I had a problem with Dnsmasq that led to my last post on understanding |
2 |
where policies come from. Now that I know and have had dnsmasq |
3 |
comfortably running with udp comms to unbound on port 553, I have run |
4 |
into the original problem that I thought I had caused. |
5 |
|
6 |
I suppose I did cause it, but not in the way I imagined. I was awash |
7 |
again with AVCs from dnsmasq, but this time I took a closer look and |
8 |
realised the source context was not as expected. Instead of running in |
9 |
dnsmasq_t, it was running in resolvconf_t. I checked the binary and that |
10 |
was as expected so I restarted using run_init just to see if that was |
11 |
the problem, and it was! So now dnsmasq is running in the correct |
12 |
context, but how did it ever get to resolvconf_t? Surely if I had |
13 |
restarted it without using run_init then it would have been in sysadm_t? |
14 |
|
15 |
One possibility is that it got into this context when my interface went |
16 |
down and up again. I had a problem last night with my Virgin fibre modem |
17 |
and I noticed that after the inevitable hardware reset, a bunch of |
18 |
services had been restarted. Besides the issue that dnsmasq is not bound |
19 |
to the interface in question, I guess I could test it quite easily, |
20 |
although I am not sure everyone else on the LAN will be too keen. |
21 |
|
22 |
Any thoughts welcome |
23 |
|
24 |
Robert Sharp |