Bug 113857

Summary: migrate_passwd.pl problems with '0' fields
Product: Red Hat Enterprise Linux 5 Reporter: Steve Bonneville <sbonnevi>
Component: openldapAssignee: Jan Zeleny <jzeleny>
Status: CLOSED ERRATA QA Contact: Jay Turner <jturner>
Severity: medium Docs Contact:
Priority: medium    
Version: 5.0CC: dspurek, omoris, rvokal, srevivo
Target Milestone: ---Keywords: Reopened
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 563172 841515 (view as bug list) Environment:
Last Closed: 2010-03-30 08:05:10 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 563172, 841515    

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):
openldap-2.0.27-11

Comment 1 RHEL 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:
http://www.redhat.com/security/updates/errata/
 
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:
http://bugzilla.padl.com/show_bug.cgi?id=345

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.

http://rhn.redhat.com/errata/RHSA-2010-0198.html