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.

Reply via email to