/etc/ppp/ip-up.d/000resolvconf doesn't check if envvar USEPEERDNS is set
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
resolvconf (Nexenta Operating System) |
New
|
Undecided
|
Unassigned | ||
resolvconf (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
Description:
When running pppd without "usepeerdns", resolvconf's scripts will take the DNS information from the IPCP.
In the script, it just checks to see if the DNS envvars are set and ignores whether or not we actually want to use it.
In the PPP provided script 0000dns, it checks the USEPEERDNS envvar and prevents this from happening.
Per PPP manpage:
"
Scripts
[..]
DNS1
If the peer supplies DNS server addresses, this variable is set to the first DNS server address supplied.
DNS2
If the peer supplies DNS server addresses, this variable is set to the second DNS server address supplied.
"
The script makes an assumption that DNS1 and DNS2 are only set if "usepeerdns" is enabled, but manpage clearly indicates it will set this envvar regardless of "usepeerdns" if IPCP receives them.
Conditions:
"usepeerdns" is not configured and IPCP provides DNS servers
Workaround:
chmod -x /etc/ppp/
Affected versions:
Tested in precise but verified scripts the same in more recent releases.
Related branches
Changed in resolvconf (Ubuntu): | |
status: | Confirmed → Fix Committed |
First of all, thanks for the report.
> but manpage clearly indicates it will set this envvar regardless
I don't see where the manpage clearly states this. Its formulation is a material implication:
The addresses supplied by the peer (if any) are passed
to the /etc/ppp/ip-up script in the environment variables
DNS1 and DNS2, and the environment variable
USEPEERDNS will be set to 1.
That these variables are *only* set, and only set to these values, under the described condition, is not explicitly said. Nor is it said that any of the variables is set, failing the described condition. Thus, so far as this text clearly states, it could be the case that if no addresses are supplied by the peer then any or all of the variables are unset, left untouched, or set to the same or other values.
If there is another passage that makes the semantics clearer then I'd be happy for you to point it out so that we can, in addition to addressing the resolvconf problem, also decide whether or not we need to improve one or more manpages.
Now, having said this, it does seems sensible for /etc/ppp/ ip-up.d/ 000resolvconf to test for USEPEERDNS having the value 1. Assuming the manpage is correct, this is safe to do. The advantage is that it prevents resolvconf from inappropriately processing DNS1 and DNS2 if they are merely passed through from the environment, for example. The fact that 0000usepeerdns itself checks the value of USEPEERDNS is also a very strong indication that this is a good idea. :)
This issue affects Debian too. I will attach a patch here which will be applied for the next Debian release.