Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Accept server host names resolvable only using /etc/hosts #281

Closed

Conversation

pspacek
Copy link
Contributor

@pspacek pspacek commented Nov 28, 2016

Apparently "files" implementation of hosts NSS database cannot deal with
trailing period in host names.

Previously name server.example.com which is was resolvable neither using
dns nor myhostname NSS modules were rejected by installer
(despite having matching line in /etc/hosts).

These names which are resolvable purely using "files" database are now
accepted.

The problem is that I had to remove trailing period from names passed
to getaddrinfo() function. This effectivelly enables search list processing.
This means that items from the search list might be silently appended to
the query and we might get an IP address for totally different names
than we asked for.

Unfortunatelly I see no way around this while keeping ability
to use names from NSS hosts database.

https://fedorahosted.org/freeipa/ticket/6518

Apparently "files" implementation of hosts NSS database cannot deal with
trailing period in host names.

Previously name server.example.com which is was resolvable neither using
dns nor myhostname NSS modules were rejected by installer
(despite having matching line in /etc/hosts).

These names which are resolvable purely using "files" database are now
accepted.

The problem is that I had to remove trailing period from names passed
to getaddrinfo() function. This effectivelly enables search list processing.
This means that items from the search list might be silently appended to
the query and we might get an IP address for totally different names
than we asked for.

Unfortunatelly I see no way around this while keeping ability
to use names from NSS hosts database.

https://fedorahosted.org/freeipa/ticket/6518
@martbab
Copy link
Contributor

martbab commented Nov 29, 2016

So can you imagine some scenario where this behavior may cause issues? Some exotic DNS setup maybe?

@pspacek
Copy link
Contributor Author

pspacek commented Nov 29, 2016

This entierly depens on configuration. Imagine following imaginary company setup:

  • public part of DNS tree is example.com.
  • private part of DNS tree is corp.
  • resolv.conf contains corp in search list

Now an admin is going to install IPA instance for publicly available services at server srv1.ipa.example.com.. The name srv1.ipa.example.com. is not resolvable as --setup-dns option is used. Now, the dns module invoked by NSS will try to lookup srv1.ipa.example.com.. It might (depending on configuration) fallback to srv1.ipa.example.com.corp. which may accidentally exist (as an IPA server for company internal purposes).

This is purely hypotetical, I'm just trying to show that the code is subtly broken.

@martbab
Copy link
Contributor

martbab commented Nov 29, 2016

I see. I guess we can live with the fact that we may break such eccentric DNS topologies.
I think we cannot really handle all the corner cases associated with guessing/setting hostname by ourselves anyway (yes I am not a big fan of FreeIPA stepping onto provisioning system's toes).

@martbab
Copy link
Contributor

martbab commented Nov 29, 2016

Thinking of this some more, shouldn't be --no-host-dns option used and advertised if you want to set unresolvable hostname during install?

@pspacek
Copy link
Contributor Author

pspacek commented Nov 29, 2016

--no-host-dns disables all checks (theoretically) so it should be used only in special cases. Given it acts as kind of force switch, we should not advertise it. In either case the user will have to provide --ip-address option. Also, the user is asked for IP address in interactive mode so IMHO we are sufficiently covered.

@martbab
Copy link
Contributor

martbab commented Nov 29, 2016

Ok I am fine with this.

@martbab martbab added the ack Pull Request approved, can be merged label Nov 29, 2016
@martbab martbab added the pushed Pull Request has already been pushed label Nov 29, 2016
@martbab martbab closed this Nov 29, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ack Pull Request approved, can be merged pushed Pull Request has already been pushed
Projects
None yet
2 participants