Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 234558 - invalid quota information reported for some numeric username
Summary: invalid quota information reported for some numeric username
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: quota
Version: 4.4
Hardware: All
OS: Linux
Target Milestone: ---
: ---
Assignee: Daniel Novotny
QA Contact: Brock Organ
Depends On:
Blocks: 432050
TreeView+ depends on / blocked
Reported: 2007-03-30 03:59 UTC by ST Wong
Modified: 2010-03-22 13:58 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2010-03-22 13:58:04 UTC
Target Upstream Version:

Attachments (Terms of Use)

Description ST Wong 2007-03-30 03:59:25 UTC
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 

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

$ quota -v
Disk quotas for user 012341234 (uid 501):
     Filesystem  blocks   quota   limit   grace   files   quota   limit   grace
                     12       0       0               1       0       0
$ id
uid=501(012341234) gid=501(012341234) groups=501(012341234) 

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
                      0       0       0               0       0       0

$ quota -v
Disk quotas for user 123412345 (uid 502):
     Filesystem  blocks   quota   limit   grace   files   quota   limit   grace
                     12       0       0               1       0       0
$ id
uid=502(123412345) gid=502(123412345) groups=502(123412345) 


Steps to Reproduce:
See above.
1. run "quota -v <username>" as root
2. run "edquota <username>" as root
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.

Comment 1 Ondrej Vasik 2008-02-08 15:45:15 UTC
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 2 RHEL Product and Program Management 2008-10-31 16:40:30 UTC
This request was evaluated by Red Hat Product Management for
inclusion, but this component is not scheduled to be updated in
the current Red Hat Enterprise Linux release. If you would like
this request to be reviewed for the next minor release, ask your
support representative to set the next rhel-x.y flag to "?".

Comment 4 Ondrej Vasik 2010-03-22 13:58:04 UTC
As RHEL-4.9 is last update for RHEL-4 and it is not suitable for new features
and should address only security, performance and critical issues, I'm closing
that bugzilla WONTFIX. 

Problem is fixed in RHEL-5 - quota-3.13-alwaysresolve.patch from RHEL-5 srpm almost applies to RHEL-4 without fuzz (just two rejects, easy to defuzz).

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