Bug 1125977 - glibc should not apply IDNA conversion before invoking NSS modules
Summary: glibc should not apply IDNA conversion before invoking NSS modules
Keywords:
Status: NEW
Alias: None
Product: Fedora
Classification: Fedora
Component: glibc
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: glibc team
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-08-01 13:56 UTC by Lennart Poettering
Modified: 2018-02-07 15:38 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed:


Attachments (Terms of Use)

Description Lennart Poettering 2014-08-01 13:56:17 UTC
Currently glibc's NSS code does IDNA processing before invoking any NSS modules, and then passes that possibly converted data to the NSS module. This is really wrong, as IDNA is specific to classic DNS, and no other host name databases use it. mDNS and LLMNR both use UTF8 data. /etc/hosts probably should operate on UTF-8 too.

In systemd we ship an NSS module that resolves the name of all locally running containers to their respective IP addresses. These container names are not DNS either.

Currently, if an NSS module wants to be compatible with 8bit hostnames and is not DNS, it must undo the IDNA conversion first, before using the data further... And that's really broken.

IDNA processing should be moved inside glibc's nss-dns module, so that it doesn't affect any other NSS modules.

Comment 1 Carlos O'Donell 2014-08-01 17:42:12 UTC
(In reply to Lennart Poettering from comment #0)
> Currently glibc's NSS code does IDNA processing before invoking any NSS
> modules, and then passes that possibly converted data to the NSS module.
> This is really wrong, as IDNA is specific to classic DNS, and no other host
> name databases use it. mDNS and LLMNR both use UTF8 data. /etc/hosts
> probably should operate on UTF-8 too.
> 
> In systemd we ship an NSS module that resolves the name of all locally
> running containers to their respective IP addresses. These container names
> are not DNS either.
> 
> Currently, if an NSS module wants to be compatible with 8bit hostnames and
> is not DNS, it must undo the IDNA conversion first, before using the data
> further... And that's really broken.
> 
> IDNA processing should be moved inside glibc's nss-dns module, so that it
> doesn't affect any other NSS modules.

I agree in principle.

If we did this right now, would the systemd NSS module tolerate not having the IDNA conversion done? That is to say is it smart enough not to try to undo the conversion if it wasn't done in the first place? The reason I ask is because of backwards compatibilty. We don't want to update glibc and break other NSS modules or require coordinated updates (hard to do and still results in partially working systems for a while during upgrade).

Comment 2 Lennart Poettering 2014-08-04 20:11:13 UTC
(In reply to Carlos O'Donell from comment #1)

> If we did this right now, would the systemd NSS module tolerate not having
> the IDNA conversion done? That is to say is it smart enough not to try to
> undo the conversion if it wasn't done in the first place? The reason I ask
> is because of backwards compatibilty. We don't want to update glibc and
> break other NSS modules or require coordinated updates (hard to do and still
> results in partially working systems for a while during upgrade).

As a result of this we currently don't allow 8bit container names... But people are asking for this (since they tend to name their containers after their possibly unicode domain names).

Note that the IDNA stuff is easily detected (since it an idna-escaped label starts with "xn--"), and optional anyway (can be requested explicitly in getaddrinfo() flags), hence NSS modules can deal with it properly, and have to deal with both IDNA and non-IDNA names anyway... So I don't think there should be any problem.

Comment 3 Fedora End Of Life 2015-05-29 12:32:20 UTC
This message is a reminder that Fedora 20 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 20. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '20'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 20 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 4 Carlos O'Donell 2015-06-03 04:39:55 UTC
Moving to rawhide as this is still a problem we want to fix.

Comment 5 Jan Kurik 2015-07-15 14:38:46 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 23 development cycle.
Changing version to '23'.

(As we did not run this process for some time, it could affect also pre-Fedora 23 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 23 End Of Life. Thank you.)

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora23

Comment 6 Fedora End Of Life 2016-11-24 11:12:05 UTC
This message is a reminder that Fedora 23 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 23. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '23'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 23 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 7 Fedora End Of Life 2017-02-28 09:37:43 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 26 development cycle.
Changing version to '26'.


Note You need to log in before you can comment on or make changes to this bug.