Package: automake;
Reported by: Petr Hracek <phracek <at> redhat.com>
Date: Wed, 30 Jan 2013 13:33:02 UTC
Severity: normal
Tags: patch
Merged with 8343
Done: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Bug is archived. No further changes may be made.
Message #54 received at 13588 <at> debbugs.gnu.org (full text, mbox):
From: Petr Hracek <phracek <at> redhat.com> To: Stefano Lattarini <stefano.lattarini <at> gmail.com> Cc: 13588 <at> debbugs.gnu.org, GNU bug tracker automated control server <control <at> debbugs.gnu.org>, Jack Kelly <jack <at> jackkelly.name>, "automake-patches <at> gnu.org" <automake-patches <at> gnu.org> Subject: Re: bug#13588: Pax hangs in case big UID Date: Mon, 22 Apr 2013 15:21:33 +0200
Hello Stefano, thanks for the patch. All is working properly. User is informed that UID is not enough smaller and configure script does not failed. Result is below: test <at> localhost: ~/mycproject$ id uid=17000000(test) gid=1001(test) groups=1001(test) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 test <at> localhost: ~/mycproject$ ./configure checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /usr/bin/mkdir -p checking for gawk... gawk checking whether make sets $(MAKE)... yes checking how to create a ustar tar archive... checking whether UID '17000000' is small enough for ustar... no none checking for style of include used by make... GNU checking for gcc... gcc checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... no checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking dependency style of gcc... gcc3 checking for pthread_create in -lpthread... yes checking for pthread_join in -lpthread... yes checking for gcc... (cached) gcc checking whether we are using the GNU C compiler... (cached) yes checking whether gcc accepts -g... (cached) yes checking for gcc option to accept ISO C89... (cached) none needed checking dependency style of gcc... (cached) gcc3 checking that generated files are newer than configure... done configure: creating ./config.status config.status: creating Makefile config.status: creating src/Makefile config.status: executing depfiles commands test <at> localhost: ~/mycproject$ On 04/20/2013 08:50 PM, Stefano Lattarini wrote: > tags 13588 + patch > stop > > [+cc automake-patches] > > Hi Jack, Petr, sorry for the ludicrous delay. > > On 03/22/2013 02:39 AM, Jack Kelly wrote: >> Petr Hracek <phracek <at> redhat.com> writes: >> >>> Hello Jack and Stefano, >>> >>> Bellow is corrected patch for automake. >>> Jack thank you for corrections. Now the patch looks like better. >> Yes, it looks a lot better. I have more thoughts, if that's ok: >> >> + # Maximum allowed UID in case ustar format is 2097151 >> >> Put a link to >> http://lists.gnu.org/archive/html/bug-automake/2011-11/msg00014.html so >> it's clear where the number came from. >> >> I'd do it like this (I've also removed the variable assignments for >> $user_id and $group_id): >> >> m4_if($1, [ustar], >> [AC_CHECK_PROG([am_prog_have_id], [id], [yes], [no]) >> if test x"$am_prog_have_id" = x"yes"; then >> # POSIX 1988 "ustar" format is defined with *fixed size* fields. There >> # is notably a 21 bits limit (2097151) for the uid and the gid. >> # http://lists.gnu.org/archive/html/bug-automake/2011-11/msg00014.html so >> am_ustar_max_id=2097151 >> ... >> if test $? -eq 0 -a `id -u` -gt $am_ustar_max_id; then >> ... >> ]) >> >> What should the user be told? It's not really their fault that the >> developer specified ustar-format archives, so perhaps the error message >> should ask the user to run configure with a lower UID or ask the user to >> ask upstream to stop using the ustar option. >> > I still believe that aborting the configure script just to signal the > user that he won't be able to run "make dist" (something only developers > do, usually) is unacceptable. And in fact, the existing code in tar.m4, > upon failing to find a working tar/pax/whatever propgram good enough to > create a tarball, didn't cause configure to abort, but merely set some > variables to ensure the error would became apparent at "make dist" time. > I think the new code should keep this behaviour. > > So, below is my first attempt of a patch. It sill passes the Automake > testsuite, but before merging it I need to know it works correctly in > real-world problematic situation it is meant to address. Petr, could > you give the patch a try and report back the results? > > Thanks, > Stefano > > ---- >8 ---- >8 ---- >8 ---- >8 ---- >8 ---- >8 ---- >8 ---- >8 ---- >8 ---- > > From 12e62106381ead9467ef7fbe14940e32aa849a61 Mon Sep 17 00:00:00 2001 > Message-Id: <12e62106381ead9467ef7fbe14940e32aa849a61.1366483309.git.stefano.lattarini <at> gmail.com> > From: Stefano Lattarini <stefano.lattarini <at> gmail.com> > Date: Sun, 17 Feb 2013 16:42:46 +0100 > Subject: [PATCH] tar: pax could hang configure when big UID are involved > > See automake bug#8343 and bug#13588. > > Tom Rini tom_rini <at> mentor.com says (in bug#8343): > > When the user has a UID or GID that is larger than the ustar format > supports, pax does not error out gracefully in some cases (FC13). > > Marc Herbert <marc.herbert <at> intel.com> adds (in bug#8343): > > When "configure" is run by a user with an UID bigger than 21 bits, > BSD pax 3.4 aborts when trying to create the 'conftest.tar' test > archive and leaves an empty or corrupted conftest.tar file behind. > In the next step, pax tries to extract this incomplete or corrupted > archive and this *** hangs the whole ./configure script ***. > > Note: GNU cpio 2.9 pretends to pass the test but it is a LIE: it > silently truncates any big UID to its lower 21 bits. I don't know > what can be the consequences of this lie. > > Months later, Petr Hracek <phracek <at> redhat.com> reports a similar issue > (in bug#13588) for Fedora 17: > > I am trying to solve problem in case a user is created with big > UID and during configuration pax hangs with message > > ATTENTION! pax archive volume change required. > Ready for archive volume: 1 > Input archive name or "." to quit pax. > Archive name > > > and needs user interaction. > > Reference: <https://bugzilla.redhat.com/show_bug.cgi?id=843376> > > Time to fix this issue, on the line of a preliminary patch provided by > Petr Hracek in bug#13588. > > * m4/tar.m4 (_AM_PROG_TAR): Don't use 'pax' if the UID or GID of the > current user is too high (> 2097151). > * NEWS: Update. > * THANKS: Likewise. > > Signed-off-by: Stefano Lattarini <stefano.lattarini <at> gmail.com> > --- > NEWS | 6 ++++++ > THANKS | 3 +++ > m4/tar.m4 | 30 +++++++++++++++++++++++++++++- > 3 files changed, 38 insertions(+), 1 deletion(-) > > diff --git a/NEWS b/NEWS > index f9a1fb1..863ffdf 100644 > --- a/NEWS > +++ b/NEWS > @@ -78,6 +78,12 @@ New in 1.13.2: > > * Bugs fixed: > > + - When the 'ustar' option is used, the generated configure script no > + longer risks hanging during the tests for the availability of the > + 'pax' utility, even if the user running configure has a UID or GID > + that requires more than 21 bits to be represented. > + See automake bug#8343 and bug#13588. > + > - The obsolete macros AM_CONFIG_HEADER or AM_PROG_CC_STDC work once > again, as they did in Automake 1.12.x (albeit printing runtime > warnings in the 'obsolete' category). Removing them has turned > diff --git a/THANKS b/THANKS > index 66498d4..a574909 100644 > --- a/THANKS > +++ b/THANKS > @@ -224,6 +224,7 @@ Luo Yi luoyi.ly <at> gmail.com > Maciej Stachowiak mstachow <at> mit.edu > Maciej W. Rozycki macro <at> ds2.pg.gda.pl > Manu Rouat emmanuel.rouat <at> wanadoo.fr > +Marc Herbert marc.herbert <at> intel.com > Marcus Brinkmann Marcus.Brinkmann <at> ruhr-uni-bochum.de > Marcus G. Daniels mgd <at> ute.santafe.edu > Marius Vollmer mvo <at> zagadka.ping.de > @@ -311,6 +312,7 @@ Peter Muir iyhi <at> yahoo.com > Peter O'Gorman peter <at> pogma.com > Peter Rosin peda <at> lysator.liu.se > Peter Seiderer seiderer123 <at> ciselant.de > +Petr Hracek phracek <at> redhat.com > Petter Reinholdtsen pere <at> hungry.com > Petteri Räty betelgeuse <at> gentoo.org > Phil Edwards phil <at> jaj.com > @@ -391,6 +393,7 @@ Tim Rice tim <at> multitalents.net > Tim Van Holder tim.van.holder <at> pandora.be > Toshio Kuratomi toshio <at> tiki-lounge.com > Tom Epperly tepperly <at> llnl.gov > +Tom Rini tom_rini <at> mentor.com > Ulrich Drepper drepper <at> gnu.ai.mit.edu > Ulrich Eckhardt eckhardt <at> satorlaser.com > Václav Haisman V.Haisman <at> sh.cvut.cz > diff --git a/m4/tar.m4 b/m4/tar.m4 > index ec8c83e..8e85d03 100644 > --- a/m4/tar.m4 > +++ b/m4/tar.m4 > @@ -81,7 +81,35 @@ do > AM_RUN_LOG([tardir=conftest.dir && eval $am__tar_ >conftest.tar]) > rm -rf conftest.dir > if test -s conftest.tar; then > - AM_RUN_LOG([$am__untar <conftest.tar]) > + m4_if([$1], [ustar], [ > + if test "$_am_tool" = pax; then > + # Automake bugs #8343 and #13588: 'pax' can hang when UIDs > + # or GIDs are involved that requires more than 21 bits to > + # be stored. > + am_max_uid=2097151 # 2^21 - 1 > + am_max_gid=$am_max_uid > + # The $UID and $GID variables are not portable, so we need to > + # resort to the POSIX-mandated id(1) utility. Errors here are > + # definitely unexpected, so allow the users to see them (i.e., > + # no stderr redirection). > + am_uid=`id -u || echo unknown` > + am_gid=`id -g || echo unknown` > + AC_MSG_CHECKING([whether UID '$am_uid' is small enough for ustar]) > + if test $am_uid -le $am_max_uid; then > + AC_MSG_RESULT([yes]) > + else > + AC_MSG_RESULT([no]) > + continue > + fi > + AC_MSG_CHECKING([whether GID '$am_gid' is small enough for ustar]) > + if test $am_gid -le $am_max_gid; then > + AC_MSG_RESULT([yes]) > + else > + AC_MSG_RESULT([no]) > + continue > + fi > + fi > + ]) # $1 == ustar > grep GrepMe conftest.dir/file >/dev/null 2>&1 && break > fi > done -- Best regards / S pozdravem Petr Hracek
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.