This service will be undergoing maintenance at 00:00 UTC, 2016-09-28. It is expected to last about 1 hours
Bug 167304 - MAXHOSTNAMELEN constant 64 too short
MAXHOSTNAMELEN constant 64 too short
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
5
All Linux
medium Severity medium
: ---
: ---
Assigned To: David Miller
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-09-01 10:31 EDT by Jason Vas Dias
Modified: 2007-11-30 17:11 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-10-16 20:58:33 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Jason Vas Dias 2005-09-01 10:31:12 EDT
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 .
Comment 1 Arjan van de Ven 2005-09-01 10:33:52 EDT
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.
Comment 2 Jason Vas Dias 2005-09-01 10:51:25 EDT
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.
Comment 3 David Miller 2005-09-21 23:54:39 EDT
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.
Comment 6 Dave Jones 2006-10-16 19:59:23 EDT
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.
Comment 7 David Miller 2006-10-16 20:58:33 EDT
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.

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