Bug 955685

Summary: Leading zeros when specifying idrange or uid/gid results in wrong values assigned without warning
Product: Red Hat Enterprise Linux 7 Reporter: Javier Ramirez <javier.ramirez>
Component: ipaAssignee: Martin Kosek <mkosek>
Status: CLOSED DEFERRED QA Contact: Namita Soman <nsoman>
Severity: low Docs Contact:
Priority: unspecified    
Version: 7.0CC: javier.ramirez, jgalipea, mkosek
Target Milestone: beta   
Target Release: 7.1   
Hardware: Unspecified   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-01-21 15:33:27 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Javier Ramirez 2013-04-23 14:14:52 UTC
Description of problem:
If you try to specify and idrange or an uid/gid using a leading zero, makes ipa to use wrong values without warning

Version-Release number of selected component (if applicable):
RHEL 6.4
ipa-server-3.0.0-26.el6_4.2.x86_64

How reproducible:
Always

Steps to Reproduce:
1. A) Install an ipaserver using a leading zero in the idmax parameter:
ipa-server-install (.......) --idstart=0101000001 --idmax=9999999999
B) Try to add an ipa user using a leading zero in the uid or gid parameters:
ipa user-add --uid=0101000001 --gid=0101000001 --first=John --last=Smith --random jsmith

  
Actual results:
A) The ipa server installation finished fine, but the idrange values are wrong:
[root@ipaserver ~]# grep dna /etc/dirsrv/slapd-SOMBREROROJO-COM/dse.ldif | grep Value
dnaNextValue: 17039361
dnaMaxValue: 9999999999

[root@ipaserver ~]# ipa idrange-show SOMBREROROJO.COM_id_range | grep ID
  First Posix ID of the range: 17039361
  Number of IDs in the range: 9982960639

As a curiosity, event the invoked command showed in the ipaserver-install.log shows the wrong values:
[root@ipaserver ~]# grep invoked /var/log/ipaserver-install.log 
2013-04-23T08:41:36Z DEBUG /usr/sbin/ipa-server-install was invoked with options: {'zone_refresh': 0, 'reverse_zone': None, 'realm_name': 'SOMBREROROJO.COM', 'create_sshfp': True, 'conf_sshd': True, 'conf_ntp': True, 'subject': None, 'no_forwarders': False, 'persistent_search': True, 'ui_redirect': True, 'domain_name': 'sombrerorojo.com', 'idmax': 9999999999, 'hbac_allow': False, 'no_reverse': False, 'dirsrv_pkcs12': None, 'unattended': False, 'selfsign': False, 'trust_sshfp': False, 'external_ca_file': None, 'no_host_dns': False, 'http_pkcs12': None, 'zone_notif': False, 'forwarders': [CheckedIPAddress('192.168.122.1')], 'idstart': 17039361, 'external_ca': False, 'ip_address': None, 'conf_ssh': True, 'serial_autoincrement': True, 'zonemgr': None, 'setup_dns': True, 'host_name': 'ipaserver.sombrerorojo.com', 'debug': False, 'external_cert_file': None, 'uninstall': False}

B) The user is added but with the wrong UID/GID:
[root@ipaserver ~]# ipa user-add --uid=0101000001 --gid=0101000001 --first=John --last=Smith --random
User login [jsmith]: 
-------------------
Added user "jsmith"
-------------------
  User login: jsmith
  First name: John
  Last name: Smith
  Full name: John Smith
  Display name: John Smith
  Initials: JS
  Home directory: /home/jsmith
  GECOS field: John Smith
  Login shell: /bin/sh
  Kerberos principal: jsmith
  Email address: jsmith
  Random password: D5jiQEXUReSZ
  UID: 17039361
  GID: 17039361
  Password: True
  Kerberos keys available: True


Expected results:
An error message or the idrange,uid/gid paremeters set to the correct values just removing the leading zeros

Additional info:

Comment 1 Rob Crittenden 2013-04-23 15:19:11 UTC
python treats numbers with leading zeroes as octal:

$  bc
bc 1.06.95
Copyright 1991-1994, 1997, 1998, 2000, 2004, 2006 Free Software Foundation, Inc.
This is free software with ABSOLUTELY NO WARRANTY.
For details type `warranty'. 
ibase=8
0101000001
17039361

Comment 2 Martin Kosek 2013-04-24 07:20:30 UTC
Interesting question. I personally tend to consider this to be rather a general "feature" of Python integer conversion and not a bug.

Comment 3 Rob Crittenden 2013-04-24 12:48:31 UTC
I wonder what we should do about this. It is certainly unexpected behavior, as people shouldn't be required to know the language we implemented in.

Then again leading 0's on an int would be ignored anyway, and few people add leading 0's to things.

We could add a test to warn about this but it is quite a corner case, and the first time I remember this coming up.

We could alternatively add this to the documentation.

Comment 5 Dmitri Pal 2013-05-07 13:31:08 UTC
Upstream ticket:
https://fedorahosted.org/freeipa/ticket/3610

Comment 6 Martin Kosek 2015-01-21 15:33:27 UTC
Thank you taking your time and submitting this request for Red Hat Enterprise Linux. Unfortunately, this bug was not given a priority and was deferred both in the upstream project and in Red Hat Enterprise Linux.

Given that we are unable to fulfill this request in following Red Hat Enterprise Linux releases, I am closing the Bugzilla as DEFERRED. To request that Red Hat re-considers the decision, please re-open the Bugzilla via appropriate support channels and provide additional business and/or technical details about its importance to you.

Note that you can still track this request or even contribute patches in the referred upstream Trac ticket.