Interesting point. Haven't thought about it much. Yes, current
/etc/resolv.conf is quite a weird configuration style in common today's
usage. I thought about proposing standard unix domain socket in /run,
but that would still be part of filesystem namespace.
Unix domain have advantage, that they are able to identify which process
with which uid and groups is asking a query. It may be used to limit
flatpak apps to be allowed just smaller set of domains. But common UDP
localhost resolver address cannot do that.
I cannot think how to pass such socket into either just alternate
namespace it the same chroot, or to complete container using also other
namespaces. But great point. If possible, this is indeed related to
network namespace and would be great to be passed into alternate
namespaces. I could think about special kind of network interface, kind
of point to point connection to main host cache.
This would be question to kernel people. If there is already some
mechanism to pass something like unix pipe into separate namespaces
already. What it would need if needs to be added.
Petr
On 19/10/2024 17:55, Andrew Lutomirski wrote:
I’m going to go out on a limb and suggest that, for the specific case
of DNS resolution, *all* current Linux mechanisms are inappropriate.
It’s a namespace and config issue:
1. /etc/resolv.conf plus an in-process resolver: /etc is an
inappropriate location, and there should not be dynamic state like
resolv.conf in /etc. Many systems kludge around this with symlinks,
but that’s a partial solution, and see below.
2. D-bus and varlink. These are at least not tied to /etc, but, just
like /etc, they’re associated with the wrong namespace!
Name resolution is part of *networking*, not filesystem. I should be
able to nsenter a network namespace and have networking work, and it
never has on Linux.
I think any new design here should find a way to tie name resolution
to the *network* namespace. I’m not sure what the best approach is,
but something involving anonymous UNIX sockets could plausibly be
workable. Ideally, though, privilege over the netns would be enforced.
It seems like it ought to be straightforward to make a kernel patch to
make a new netlink family that needs CAP_NET_ADMIN to bind but allows
anyone to send. Or perhaps a protocol could be designed that works by
binding to a well known port, below 1024, localhost-only, on a well
known IPv4 or v6 address.
--
Petr Menšík
Software Engineer, RHEL
Red Hat, https://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
--
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
