Bug 234558 - invalid quota information reported for some numeric username
invalid quota information reported for some numeric username
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: quota (Show other bugs)
4.4
All Linux
medium Severity medium
: ---
: ---
Assigned To: Daniel Novotny
Brock Organ
:
Depends On:
Blocks: 432050
  Show dependency treegraph
 
Reported: 2007-03-29 23:59 EDT by ST Wong
Modified: 2010-03-22 09:58 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-03-22 09:58:04 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 ST Wong 2007-03-29 23:59:25 EDT
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.
Comment 1 Ondrej Vasik 2008-02-08 10:45:15 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 2 RHEL Product and Program Management 2008-10-31 12:40:30 EDT
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 09:58:04 EDT
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.