change in readlink() errno in 2.6.39 and later kernels causes FTBFS for packages with older gnulib

[Jamie Strandboge]

When building packages in a chroot with gnulib testcases for readlink() on a 2.6.39 (Oneiric or newer) kernel, these packages may FTBFS. This is due to the following:
http://lists.gnu.org/archive/html/bug-gnulib/2011-03/msg00308.html

"coreutils' "make check" failed on rawhide due to a kernel change
in how readlink and readlinkat treat the empty file name.
Before, they'd fail with ENOENT. Now, it's EINVAL."

This was discovered when preparing security updates for libvirt, but will affect more than libvirt, (see Debian http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=630902). For libvirt, the patch in the above bug can be applied to gnulib/tests/test-areadlink.h to get these building again on newer releases. This is SRU-worthy, as libvirt will not build once the buildds are running newer kernels. If it is not SRUd before the next security update, the security team will do it as part of their update process.

Upstream kernel commit that introduced the change: 65cfc6722361570bfe255698d9cd4dccaf47570d

[Jamie Strandboge (jdstrand)]

libvirt in Oneiric builds fine.

[Brad Figg (brad-figg)]

This bug is missing log files that will aid in diagnosing the problem. From a terminal window please run:

apport-collect 817187

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

[Jamie Strandboge (jdstrand)]

This doesn't need log files. Attached is a simple reproducer.

[Andy Whitcroft (apw)]

This is a notty one. The behavour has indeed changed, ENOENT was the previous return and now we return EINVAL. I do not have a POSIX manual to hand, but the gist of the restriction is as below:

   Empty pathname
       In the original Unix, the empty pathname referred to the current
       directory. Nowadays POSIX decrees that an empty pathname must not be
       resolved successfully. Linux returns ENOENT in this case.

It could be argued that the new behaviour is just as valid. A change is however unhelpful. Especially as kernel behaviour is exposed in chroots.

[Andy Whitcroft (apw)]

A quick review of other syscalls reacting to "" as a pathname tend to now place readlink as an inconsistant outsider:

  open("", O_RDONLY) = -1 ENOENT (No such file or directory)
  chmod("", 0777) = -1 ENOENT (No such file or directory)
  readlink("", 0x7fff794533c0, 2048) = -1 EINVAL (Invalid argument)
  stat("", 0x7fff79453330) = -1 ENOENT (No such file or directory)
  rename("", "") = -1 ENOENT (No such file or directory)
  unlink("") = -1 ENOENT (No such file or directory)

[Kees Cook (kees)]

Packages with gnulib in their source:

main:

augeas
binfmt-support
eglibc
findutils
gdb
glib2.0
groff
grub2
hello
hello-debhelper
liblouis
libpipeline
libtasn1-3
libvirt
man-db
mlocate
texinfo

universe/multiverse:

amanda
eiskaltdcpp
freedink
genparse
hivex
instantbird
libdc0
libdrizzle
liblouisxml
mpop
msmtp
z80asm

[Andy Whitcroft (apw)]

Have started a thread upstream to discuss this change.

[JC Hulce (soaringsky)]

This bug affects Ubuntu 10.10, Maverick Meerkat. Maverick has reached end-of-life and is no longer supported, so I am closing the bugtask for Maverick. Please upgrade to a newer version of Ubuntu.
More information here: https://lists.ubuntu.com/archives/ubuntu-announce/2012-April/000158.html

[dino99 (9d9)]

eol reached https://wiki.ubuntu.com/Releases

[Rolf Leggewie (r0lf)]

lucid has seen the end of its life and is no longer receiving any updates. Marking the lucid task for this ticket as "Won't Fix".