Re: [PATCH] conf: Follow changes to the host nameserver used for DNS forwarding

[Aditya Merchant <adityamerchant08@gmail.com>]

Hi Stefano,

On Fri, 13 Nov 2026 01:09:29 +0100
Stefano Brivio <sbrivio@redhat.com> wrote:

> Thanks for looking into this part.  It looks like sysnet_watch_config()
> is exactly what we need here, so I think we should add that on top of
> the existing sysnet_read_config() rules. Note that I haven't tested
> this (yet).

I had a look: sysnet_watch_config() allows watches on net_conf_t files
and links, but we watch the directory holding resolv.conf, and SELinux
checks the inode being watched, so for /etc that's etc_t. In v2, which I
just sent, I used files_watch_etc_dirs() instead, plus
networkmanager_watch_pid_dirs() and systemd_resolved_watch_pid_dirs()
for links into /run/NetworkManager and /run/systemd/resolve. It builds
against Fedora 45's policy (for /etc, it adds "allow pasta_t etc_t:dir
{ getattr watch }"), but I couldn't try it with SELinux enforcing.

> I think it *might* be worth it, but I'm not sure how complicated that
> is, so I'm fine either way.  If it's a few lines (20 or so?) I would
> suggest giving it a try.

It's under 20 lines: in a separate mount namespace, an overlay mounted on
/etc lets the test replace resolv.conf. It's test/pasta_options/
dns_host_follow in v2, and it fails without the patch.

> - just get rid of it and hardcode that, parsing only the directory part
>   in conf_resolv_watch()?  Can we safely do that?

Almost: if resolv.conf is a link, its target can have another name. But
the usual one, systemd-resolved's stub-resolv.conf, always lists
127.0.0.53, so there's nothing to follow there. v2 hard-codes
"resolv.conf", and doesn't follow anything else.

> Couldn't this feature be useful for passt(1) as well, by the way?

I think so, for guests using --dns-forward. But passt doesn't allow
openat() in its seccomp filter, and I didn't want to add that without
asking. Would you like it as a follow-up patch?

> ...but we don't know if it's failing because of an older kernel, or
> because of some other issue that we shouldn't ignore.  And in any case,
> it's probably not a good idea to introduce this mechanism in a less
> secure way for kernel versions between 5.2 and 5.12: I'd rather goto
> fail; here.

Done.

> For robustness, we should make sure that 'buf' is zero-terminated here,
> see how passt-repair's wait_for_socket() handles this.
>
> True, pasta_netns_quit_inotify_handler() doesn't do that (and we should
> fix that as well), but at least it uses strncmp().

Done, and patch 2/2 does the same in pasta_netns_quit_inotify_handler().

> Shouldn't we break here?

Yes, done.

> I'm wondering if we shouldn't include <abstractions/nameservice>
> instead.  It's much broader but probably more compatible and also the
> right thing to do.  I haven't checked whether that works, though.

I tried it: /etc/resolv.conf still works, but links into /run stop
working, because files on the detached copy show up with paths relative
to /run (AppArmor denied "/resolvconf/resolv.conf" and
"/systemd/resolve/resolv.conf"), and nameservice only has the full
paths. So I kept the explicit rule.

Thanks a lot for the review!

--
Aditya