Bug 113857 - migrate_passwd.pl problems with '0' fields
Summary: migrate_passwd.pl problems with '0' fields
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: openldap (Show other bugs)
(Show other bugs)
Version: 5.0
Hardware: All Linux
Target Milestone: ---
: ---
Assignee: Jan Zeleny
QA Contact: Jay Turner
Keywords: Reopened
Depends On:
Blocks: 563172 841515
TreeView+ depends on / blocked
Reported: 2004-01-19 16:05 UTC by Steve Bonneville
Modified: 2015-01-08 00:07 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 563172 841515 (view as bug list)
Last Closed: 2010-03-30 08:05:10 UTC
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 13:22:42 UTC

Description Steve Bonneville 2004-01-19 16:05:34 UTC
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 19:31:13 UTC
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 19:45:29 UTC
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 12:55:59 UTC
reported upstream, together with a patch:

Comment 5 Jan Zeleny 2009-11-16 09:51:24 UTC
Patch is in CVS, changing status to MODIFIED.

Comment 7 Ondrej Moriš 2009-11-25 14:39:15 UTC
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 08:05:10 UTC
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.