Bug 432050 - invalid quota information reported for some numeric username
invalid quota information reported for some numeric username
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: quota (Show other bugs)
5.2
All Linux
medium Severity medium
: ---
: ---
Assigned To: Ondrej Vasik
Brock Organ
:
Depends On: 234558
Blocks:
  Show dependency treegraph
 
Reported: 2008-02-08 10:51 EST by Ondrej Vasik
Modified: 2013-04-12 15:32 EDT (History)
2 users (show)

See Also:
Fixed In Version: RHBA-2008-0637
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-07-30 09:08:22 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Ondrej Vasik 2008-02-08 10:51:26 EST
+++ This bug was initially created as a clone of Bug #234558 +++

Description of problem:
edquota and "quota -v <username>" reports incorrect user and uid information 
for numeric usernames, and the quota value reported is incorrect.  There is no 
problem if "quota -v" is executed by these users themselves:



I wonder if numeric username is supported, and whether there is any other 
contraint in usernames on RHEL AS 4 or 5, e.g. username length.


Version-Release number of selected component (if applicable):
RHEL AS 4 Update 4 i386

How reproducible:
-----------------------------------------------------------------------
Case 1: When numeric username starts with zero, both user and uid are 
incorrect,e.g

#quota -v 012341234
Disk quotas for user #2736796 (uid 2736796):
     Filesystem  blocks   quota   limit   grace   files   quota   limit   grace
/dev/mapper/VolGroup01-lvol0
                      0       0       0               0       0       0

$ quota -v
Disk quotas for user 012341234 (uid 501):
     Filesystem  blocks   quota   limit   grace   files   quota   limit   grace
/dev/mapper/VolGroup01-lvol0
                     12       0       0               1       0       0
$ id
uid=501(012341234) gid=501(012341234) groups=501(012341234) 
context=user_u:system_r:unconfined_t


-----------------------------------------------------------------------
Case 2: Numeric username doesn't start with zero, uid is the same as username:
#quota -v 123412345
Disk quotas for user #123412345 (uid 123412345):
     Filesystem  blocks   quota   limit   grace   files   quota   limit   grace
/dev/mapper/VolGroup01-lvol0
                      0       0       0               0       0       0


$ quota -v
Disk quotas for user 123412345 (uid 502):
     Filesystem  blocks   quota   limit   grace   files   quota   limit   grace
/dev/mapper/VolGroup01-lvol0
                     12       0       0               1       0       0
$ id
uid=502(123412345) gid=502(123412345) groups=502(123412345) 
context=user_u:system_r:unconfined_t

-----------------------------------------------------------------------

Steps to Reproduce:
See above.
1. run "quota -v <username>" as root
2. run "edquota <username>" as root
3. 
  
Actual results:
Incorrect quota and user information reported

Expected results:
Correct quota and user information reported

Additional info:
There is no problem if there is at least 1 alphabet (regardless of location) 
in the username, e.g. a12341234, 12341234a.

-- Additional comment from ovasik@redhat.com on 2008-02-08 10:45 EST --
Thanks for reporting that.  Problem is in user2uid() function which is used by
quota commands. That one does not work for numeric/octal/hexadecimal names as it
uses strtoul to check if user did provided username and not directly userid -
but that doesn't work correctly in the case of octal/hexadecimal/fullynumeric name. 

Long option for that issue was added in linuxquota-3.14 (--always-resolve ) - to
skip that check. So if you need numeric/octal/hexadecimal usernames/groupnames,
please use Fedora quota package(at least F7) until it will be fixed in RHEL.
Decreasing severity to medium (as there is no risk of data loss/crash of
systems) - it is just loss of functionality which should be fixed.
Comment 7 errata-xmlrpc 2008-07-30 09:08:22 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.

http://rhn.redhat.com/errata/RHBA-2008-0637.html

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