On Sa, 19.10.24 08:55, Andrew Lutomirski (luto@xxxxxxx) wrote: > 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. Uh, no. That's not really how this works though. Network namespaces on Linux pretend to be orthogonal to other classes of namespacing, but it's not really true. Except for trivial cases when you manage a network namespace you typically need access to /sys/class/net/ and /proc/sys/net/ (because plenty of the knobs associated with network interfaces are exposed as sysctl or as sysfs attribute, and not purely over rtnetlink). To get a correctly working procfs/sysfs matching your network namespace you must mount them from inside the network namespace. Which hence effectively means: in any real-life case a network namespace *implies* a mount namespace. And because of that I think it's fine to also say the entrypoint for DNS resolution shall be in the file system too. > 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. I vehemently disagree: the anonymous AF_UNIX namespace should not be used anymore for listening sockets, because any process can take any socket without access control. It's only safe if you basically take a randomized name, and then store a reference to it at a reasonably place (for example in the fs), but then you might as well use a proper AF_UNIX socket in the fs right-away and simplify things. Sorry, but anonymous AF_UNIX listener sockets are an instant DoS, do not use them. The Varlink approach fits the sandboxed/containerized approach really nicely btw, because it has a delegation model built-in: to delegate DNS resolver access to a container, it suffices to bind mount the host's socket for that into the container. This is a model not available to D-Bus (since *everything* is multiplex over the same socket). Lennart -- Lennart Poettering, Berlin -- _______________________________________________ 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
