Red Hat Bugzilla – Bug 167304
MAXHOSTNAMELEN constant 64 too short
Last modified: 2007-11-30 17:11:12 EST
Description of problem: I'd just like to open this issue up for discussion: The DNS RFC 1035 states, in Section 2.3.4, 'Size limits': " labels 63 octets or less names 255 octets or less ". ie. host names up to 255 characters are supported by DNS and BIND, yet in the glibc-kernheaders, we see : asm/param.h: #define MAXHOSTNAMELEN 64 Which is the maximum length of a LABEL (a name which does not include unescaped '.'s, but which MAY include '\.'s), plus one for the '\0' terminator. Yet the POSIX limit is correct: bits/posix1_lim.h: #define _POSIX_HOST_NAME_MAX 255 So it looks like the linux headers have the wrong MAXHOSTNAMELEN for DNS host names - it should be 256, not 64. Indeed, all the host name utilities incorrectly enforce this 63 character limit on host names - in rawhide, I can't set the hostname to a valid DNS name: $ hostname \ l012345678012345678012345678012345678012345678012345678012345678012345678 hostname: name too long $ hostname \ l01234567801234567801234567801234567801234567801234567801234567.8012345678 hostname: name too long $ hostname L01234567801234567801234567801234567.L8012345678012345678012345678012345678 hostname: name too long Even though I can define such a name in the DNS : $ host \ 012345678_012345678_012345678_012345678_012345678_012345678_01.012345678_012345678_012345678_012345678_012345678_012345678_01.012345678_012345678_012345678_012345678_012345678_012345678_01.012345678_012345678_012345678_012345678_012345678.01234.jvds.net. 012345678_012345678_012345678_012345678_012345678_012345678_01.012345678_012345678_012345678_012345678_012345678_012345678_01.012345678_012345678_012345678_012345678_012345678_012345678_01.012345678_012345678_012345678_012345678_012345678.01234.jvds.net has address 64.32.16.9 The MAXHOSTNAMELEN constant should be defined as 256 ; the value of 64 gives the misleading impression to application programs that the maximum host name length that can be returned by DNS queries is 63 bytes, when in fact it is 255 bytes, potentially leading to buffer overflows. Version-Release number of selected component (if applicable): This could be due to a fundamental limitation in either the kernel or glibc - I'm not sure which . How reproducible: 100% Steps to Reproduce: Attempt to set hostname to legal 255 byte DNS name Actual results: Attempt fails Expected results: You should be able to set the hostname to any legal DNS name .
MAXHOSTNAMELEN is the maximum the kernel accepts for a hostname and has no correlation to DNS or anything like that. Any code that assumes so is terminally broken and shouldn't use kernel headers.
It seems the kernel has an incorrect assumption about the maximum length of a host name, which is defined by the DNS RFCs and POSIX to be 255 bytes, but is incorrectly enforced by the kernel to be 63 bytes. I'd just like to flag this issue so that hopefully in the long term it can be fixed and the kernel will accept a host name that is as long as DNS and POSIX allow.
The kernel seems to not even care what value MAXHOSTNAMELEN has, as nothing in the kernel tests it. The kernel actually uses __NEW_UTS_LEN which is also set to "64" and this value cannot be changed because it's size is encoded into several datastructures including struct old_utsname and struct new_utsname, whose layout is known by userspace. We really can't fix this, but I'll leave this in INVESTIGATE in case someone else can figure out a way.
A new kernel update has been released (Version: 2.6.18-1.2200.fc5) based upon a new upstream kernel release. Please retest against this new kernel, as a large number of patches go into each upstream release, possibly including changes that may address this problem. This bug has been placed in NEEDINFO state. Due to the large volume of inactive bugs in bugzilla, if this bug is still in this state in two weeks time, it will be closed. Should this bug still be relevant after this period, the reporter can reopen the bug at any time. Any other users on the Cc: list of this bug can request that the bug be reopened by adding a comment to the bug. In the last few updates, some users upgrading from FC4->FC5 have reported that installing a kernel update has left their systems unbootable. If you have been affected by this problem please check you only have one version of device-mapper & lvm2 installed. See bug 207474 for further details. If this bug is a problem preventing you from installing the release this version is filed against, please see bug 169613. If this bug has been fixed, but you are now experiencing a different problem, please file a separate bug for the new problem. Thank you.
I'm closing this with WONTFIX because in more than half a year nobody has come up with a userland compatible way of fixing this sans adding a totally new system call providing a larger name string which seems like extreme overkill and waste of previous system call slot just for this.