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.
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.
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 "?".
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).