You are not logged in.
Pages: 1
I want to know if it is possible to have a non-root hosts file in a user's home directory.
The dns resolver (I am using dnsmasq, suggest others if needed) must give precedence to this file over the global one (/etc/hosts).
Last edited by desperado (2021-05-18 16:30:17)
Offline
Knowing others is wisdom, knowing yourself is enlightenment. ~Lao Tse
Offline
Hostnames are in most cases resolved by making calls to glibc (e.g. via getaddrinfo()), which then uses the information in the `hosts` line in nsswitch.conf(5) to determine what sources to use for resolving hostnames.
By default, the `hosts` line will look something like this:
hosts: files mymachines myhostname resolve [!UNAVAIL=return] dns
So it will first check /etc/hosts; then the names of local machines (systemd-machined/nspawn); then the local hostname itself; then systemd-resolved; and then finally (only if resolved is not running) make a direct request to a nameserver as specified in /etc/resolv.conf.
If I understood your issue correctly, you want glibc to first check a user-specific file before proceeding to read from /etc/hosts and other sources. For that, you'd need to install a libnss DB that provides that functionality (i.e. /usr/lib/libnss_[…].so), and then specify it in the `hosts` line there as the first entry.
I don't know if such an NSS DB exists, but AFAICT that would be the cleanest way. But maybe others have better/easier suggestions.
--edit: I just noticed that you mentioned dnsmasq. How are you interacting with dnsmasq? Did you specify it as a resolver in /etc/resolv.conf?
Note that given the order of sources in nsswitch.conf, /etc/hosts will be read before dnsmasq is queried, so putting this sort of functionality into dnsmasq won't do much here (unless you also change the order of entries in the `hosts` line).
Last edited by ayekat (2021-05-18 07:51:44)
Offline
I don't know if such an NSS DB exists
It does seem to exist, https://github.com/bAndie91/libnss_homehosts
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
It does seem to exist, https://github.com/bAndie91/libnss_homehosts
Ouh, that is nice to know, thanks for the link!
And the mandatory AUR package that also exists, of course: https://aur.archlinux.org/packages/libn … hosts-git/
Offline
Here are my config files.
> cat resolv.conf
nameserver 1.1.1.1
nameserver 8.8.8.8
> cat /etc/hosts
127.0.0.1 localhost
I never touched nsswitch.conf before.
I'm using networkmanager (in the place of systemd-networkd) + dnsmasq (in the place of systemd-resolved) if that makes a difference.
/etc/hosts will be read before dnsmasq is queried
Are you saying dnsmasq has nothing to do with name resolution?
Last edited by desperado (2021-05-18 12:14:26)
Offline
ayekat wrote:/etc/hosts will be read before dnsmasq is queried
Are you saying dnsmasq has nothing to do with name resolution?
No, that's not what I was saying.
Yes, dnsmasq provides a DNS server. But in order to use it e.g. as a local caching server, your system and dnsmasq itself also need to be configured accordingly.
Based on the configuration you have shown us, that isn't the case yet. /etc/resolv.conf points to 1.1.1.1 and 8.8.8.8—and as you're using NetworkManager (and haven't otherwise touched nsswitch.conf), that's probably all there is, as systemd-resolved isn't used.
But really, that's besides the point: Even if dnsmasq was set up as a local DNS resolver, /etc/hosts would still be queried first, unless you changed the order of the entries in the `hosts` line in /etc/nsswitch.conf.
And even if you set up everything such that dnsmasq is queried first, dnsmasq wouldn't have any way of knowing which local system user did a name lookup, so it can't really dynamically choose a user-specific hosts file to read entries from.
Based on my current understanding of the name lookup procedure in glibc, the functionality you want is not possible with dnsmasq.
You will need something like libnss_homehost.so linked above.
Offline
I thought so too, but that dude booted me to the manpage and there I saw an option named "hostsdir". I need to test it.
Problem is that "dnsmasq.service" isn't a user-level service, which makes sense because it listens on port 53. I just want to keep all dnsmasq functionality in the non-privileged level (guess I haven't mentioned that in the question). This part is solved I suppose.
About dnsmasq, I read that it starts as root, but drops to user nobody (default non-privileged user) soon afterwards. I'll try and see if the root part can be eliminated. If not I'll post another thread.
Last edited by desperado (2021-05-18 16:31:52)
Offline
I just want to keep all dnsmasq functionality in the non-privileged level (guess I haven't mentioned that in the question).
That doesn't really solve anything, because only one user would be able to run dnsmasq at once (and it would also affect the entire system, not just that one specific user, so really you're just making things less secure and a lot more complicated).
Again, libnss_homehost seems like the cleanest approach by far. I would forget about dnsmasq for now; I don't see how it solves any issues here.
But also… why? What problem are you trying to solve here? Why do you actually need user-specific hosts files?
This sounds more and more like an XY problem to me.
Last edited by ayekat (2021-05-18 22:06:57)
Offline
Oh no, that's not what I meant. It's more "url fetching is a user level thing, so dns must be a user level thing too". But yeah you're right about only one user being able to run dnsmasq. So forget about non-root dnsmasq.
The ideal scenario would be to probably have seperate a hosts file for each user (in addition to the common /etc/hosts). For example, unprivileged user B cannot access entries from unprivileged user A's custom hosts file. But dnsmasq doesn't seem to support that.
So with this homehosts thing, dnsmasq isn't needed at all?
Edit -
Homehosts seems to be just an extension to nss. So they are supposed to be used together. I kind of like this solution because you don't have to deal with extra dnsmasq braindeath.
Last edited by desperado (2021-05-19 05:58:14)
Offline
Pages: 1