Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 113857 - migrate_passwd.pl problems with '0' fields
migrate_passwd.pl problems with '0' fields
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: openldap (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jan Zeleny
Jay Turner
: Reopened
Depends On:
Blocks: 563172 841515
  Show dependency treegraph
Reported: 2004-01-19 11:05 EST by Steve Bonneville
Modified: 2015-01-07 19:07 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 563172 841515 (view as bug list)
Last Closed: 2010-03-30 04:05:10 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2010:0198 normal SHIPPED_LIVE Moderate: openldap security and bug fix update 2010-03-29 09:22:42 EDT

  None (edit)
Description Steve Bonneville 2004-01-19 11:05:34 EST
Another migration scripts issue, this time with migrate_passwd.pl.

If a field in the shadow password file contains a 0 digit, then the
attribute/value will not be set in the LDIF output.  In particular,
this affects shadowMin, which is 0 by default and therefore will never
be set.  

Offending Perl code is in the dump_shadow_attributes routine, where we
have tests like the following on lines 205-207:

        if ($min) {
                print $HANDLE "shadowMin: $min\n";

So, if $min is a 0, then the expression is false and the attribute is
not output.  The code should really be using the 'defined' operator here.

This issue exists throughout the script; any field containing a 0 in
/etc/passwd or /etc/shadow will be skipped.  The only reason the root
account migrates properly is because of hackish stuff on lines 155-165:

        if ($uid ne "") {
                print $HANDLE "uidNumber: $uid\n";
        } else {
                print $HANDLE "uidNumber:\n";
        if ($gid ne "") {
                print $HANDLE "gidNumber: $gid\n";
        } else {
                print $HANDLE "gidNumber:\n";

...which is DOUBLY gross because uidNumber and gidNumber are required
attributes and we don't issue any sort of warning!

Version-Release number of selected component (if applicable):
Comment 1 RHEL Product and Program Management 2007-10-19 15:31:13 EDT
This bug is filed against RHEL 3, which is in maintenance phase.
During the maintenance phase, only security errata and select mission
critical bug fixes will be released for enterprise products. Since
this bug does not meet that criteria, it is now being closed.
For more information of the RHEL errata support policy, please visit:
If you feel this bug is indeed mission critical, please contact your
support representative. You may be asked to provide detailed
information on how this bug is affecting you.
Comment 2 Steve Bonneville 2007-10-19 15:45:29 EDT
Updated version to RHEL 5.  Same bugs exist in the same file in the
openldap-2.3.27-5 package, add three to all line number counts above.
Comment 3 Jan Safranek 2007-10-22 08:55:59 EDT
reported upstream, together with a patch:
Comment 5 Jan Zeleny 2009-11-16 04:51:24 EST
Patch is in CVS, changing status to MODIFIED.
Comment 7 Ondrej Moriš 2009-11-25 09:39:15 EST
Bug-fix verified by RHTS test with success. See [1].

[1] http://rhts.redhat.com/cgi-bin/rhts/jobs.cgi?id=103756
Comment 9 errata-xmlrpc 2010-03-30 04:05:10 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.


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