On 2021/01/15 08:27, Landry Breuil wrote: > On Thu, Jan 14, 2021 at 08:44:00PM +0000, Stuart Henderson wrote: > > On 2021/01/07 16:45, Stuart Henderson wrote: > > > On 2021/01/07 16:31, Stefan Hagen wrote: > > > > Hello, > > > > > > > > I've blocked the DoT port and the top DoH servers on my network in > > > > order > > > > to force all my clients to use my own DNS server. It then happened that > > > > Firefox was not able to resolve any domain anymore. > > > > > > > > After some tracing, it turned out that the main process wants to read > > > > /etc/resolv.conf, but is not allowed to because unveil blocks it. > > > > > > > > I thinks its reasonable to let firefox access resolv.conf. > > > > > > I don't think this should be done via unveil. > > > > > > Firefox GPU and main processes have pledge "dns" which bypass unveil to > > > permit access to /etc/resolv.conf. So I guess this must be the content > > > process. > > > > I've changed my mind on this, there are cases where Firefox can't be > > used unless pledge is disabled, but it seems sensible to still allow > > unveil in that case. landry, jcs: what do you think? > > i dont understand any of this anyway :) > > you want to add resolv.conf to unveil just for the case when one has > disabled pledge but still uses unveil, because in the default case dns > pledge allows access to resolv.conf if unveil is also used ? corner > case, but whatever.. fine with me !
exactly. Thanks, I'll add comments to explain this and commit. > fwiw, the code is always a reference. looking for resolv.conf on > searchfox.org > (https://searchfox.org/mozilla-central/search?q=resolv.conf&path=) > yields two hits: > https://searchfox.org/mozilla-central/source/ipc/chromium/src/third_party/libevent/evdns.c#3963 > (dunno if this codepath is actually used) > and > https://searchfox.org/mozilla-central/source/netwerk/dns/nsHostResolver.cpp > > the last one shows that firefox doesnt do anything special parsing > resolv.conf, rather (if i understand it after looking 5s) tries to reset > the internal resolver state if a lookup fails (and RES_RETRY_ON_FAILURE > is defined, which is if res_ninit() is found). dunno if that only works > fine with glibc though, we dont seem to have such function. the libc resolver functions use resolv.conf, unveil/pledge need to allow access to the file for this to work. > maybe that's the place ppl should look at to fix the 'i dont have dns > resolution anymore if i switch networks or suspend/resume' bug.