Bug 843376 - configure stops when run by big UID
Summary: configure stops when run by big UID
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: automake   
(Show other bugs)
Version: 17
Hardware: All
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Petr Hracek
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-07-26 07:23 UTC by Thomas Lofgren
Modified: 2013-06-16 06:11 UTC (History)
4 users (show)

Fixed In Version: automake-1.13.2-1.fc19
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-05-02 11:19:46 UTC
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

Description Thomas Lofgren 2012-07-26 07:23:11 UTC
Description of problem:
When running a configure (autoconf) with a uid higher then 21 bits (i.e winbind) pax will hang forever.
This is very clear when trying to build a cross compiler and PPL lib.

Version-Release number of selected component (if applicable):
pax 3.4

How reproducible:
Create an user with uid bigger then 21 bit (for example 16777216) and run configure on PPL.

Steps to Reproduce:
1. Create test user with id > 21 bits
2. Run configure on PPL version 0.11.2 (example)
  
Actual results:
Configure hangs with message:
ATTENTION! pax archive volume change required.
Ready for archive volume: 1
Input archive name or "." to quit pax.
Archive name > 

Expected results:
Configure will exit (successfully or unsuccessfully)


Additional info:
Bug filed att GNU on this with bug#8343: hangs the whole configure script
http://lists.gnu.org/archive/html/bug-automake/2011-11/msg00014.html

Comment 1 Pavel Raiskup 2012-08-17 15:29:08 UTC
Hello Thomas, thanks for your report!

This is because the line in configure.ac:

> AM_INIT_AUTOMAKE([... tar-ustar ...])

And the ustar format of tar archive is designed to store at most uids of 21
bits.

I'm not sure if pax is the correct component to address this bug.  It seems
that this should be switched to 'autoconf'.  I have tried pax with big-uid
user:

   $ echo $UID
   17000000
   $ echo "content" > FILE
   $ pax -w -f file.tar FILE
   pax: Ustar header field is too small for FILE
   [bignum@raiskup testoftar]$ echo $?
   1

And 'pax' is throwing *correctly* the return value 1.  So the configure script
should probably at least take this error output into account and fail.

I'll switch this bug to autoconf but feel free to re-switch it to pax if you
feel it is the correct target.

===

Side notes (when asking for ustar format):
  - distributed pax fails correctly on 'ustar' (retval = 1)
  - gnu tar correctly fails
  - star "succeeds" but it trims UID at 21 bits

Btw., when the pax utility is not present on the system, gnu tar is used on
Fedora by configure script and the configure script succeeds (even if gnu tar
fails on big uids).

===

The correct way how to deal with big uids is probably to use 'pax' (newer
posix) format that is not yet correctly supported by GNU tar.

Pavel

Comment 2 Petr Hracek 2013-01-29 09:11:13 UTC
This bug is relevant to automake.

Patch was send to upstream.
http://lists.gnu.org/archive/html/automake/2013-01/msg00079.html

Comment 3 Petr Hracek 2013-01-29 09:23:01 UTC
This bug is reassigned to automake

Comment 4 Petr Hracek 2013-05-02 11:19:46 UTC
How to test:

description is mentioned in Steps to Reproduce:
scm-commit (http://lists.fedoraproject.org/pipermail/scm-commits/Week-of-Mon-20130429/1009087.html) -> CLOSED RAWHIDE

Comment 6 Fedora Update System 2013-06-03 08:23:01 UTC
automake-1.13.2-1.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/automake-1.13.2-1.fc19

Comment 7 Fedora Update System 2013-06-16 06:11:40 UTC
automake-1.13.2-1.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.


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