Debian Bug report logs - #705483
xfsprogs: xfs_quota misinterprets usernames with leading digits

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: James Carter <james.carter@bytemark.co.uk>

To: submit@bugs.debian.org

Subject: xfsprogs: xfs_quota misinterprets usernames with leading digits

Date: Mon, 15 Apr 2013 15:46:51 +0100

Subject: xfsprogs: xfs_quota misinterprets usernames with leading digits
Package: xfsprogs
Version: 3.1.4
Severity: normal

*** Please type your report below this line ***

xfs_quota interprets usernames with leading digits as a numeric UID so,
for example:

# xfs_quota -c 'quota -h -u 2000ad' /store
Disk quotas for User test (2000)
Filesystem   Blocks  Quota  Limit Warn/Time    Mounted on
/dev/sdb1       12K     1G     1G  00 [------] /store

This is returning quota information for the user "test" (UID 2000), rather
than the user "2000ad".

-- System Information:
Debian Release: 6.0.7
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-0.bpo.4-amd64 (SMP w/12 CPU cores)
Locale: LANG=en_GB, LC_CTYPE=en_GB (charmap=UTF-8) (ignored: LC_ALL set 
to en_GB.UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages xfsprogs depends on:
ii  libblkid1                     2.17.2-9   block device id library
ii  libc6                         2.11.3-4   Embedded GNU C Library: 
Shared lib
ii  libreadline5                  5.2-7      GNU readline and history 
libraries
ii  libuuid1                      2.17.2-9   Universally Unique ID library

xfsprogs recommends no packages.

Versions of packages xfsprogs suggests:
pn  acl <none>     (no description available)
pn  attr <none>     (no description available)
pn  quota <none>     (no description available)
pn  xfsdump <none>     (no description available)

-- no debconf information

-- 
James Carter                                           Bytemark Hosting
                                             http://www.bytemark.co.uk/
                                              tel: +44 (0) 1904 890 890

Message #10 received at submit@bugs.debian.org (full text, mbox, reply):

From: Rich Johnston <rjohnston@sgi.com>

To: James Carter <james.carter@bytemark.co.uk>, <705483@bugs.debian.org>

Cc: <submit@bugs.debian.org>

Subject: Re: Bug#705483: xfsprogs: xfs_quota misinterprets usernames with leading digits

Date: Mon, 15 Apr 2013 11:07:08 -0500

On 04/15/2013 09:46 AM, James Carter wrote:
> Subject: xfsprogs: xfs_quota misinterprets usernames with leading digits
> Package: xfsprogs
> Version: 3.1.4
> Severity: normal
>
> *** Please type your report below this line ***
>
> xfs_quota interprets usernames with leading digits as a numeric UID so,
> for example:
>
> # xfs_quota -c 'quota -h -u 2000ad' /store
> Disk quotas for User test (2000)
> Filesystem   Blocks  Quota  Limit Warn/Time    Mounted on
> /dev/sdb1       12K     1G     1G  00 [------] /store
>
> This is returning quota information for the user "test" (UID 2000), rather
> than the user "2000ad".
>

I don't think this is a bug, username must begin with a character 
(unless you created the user using NIS or adduser --force-badname).

# Default from /etc/adduser.conf
# check user and group names also against this regular expression.
#NAME_REGEX="^[a-z][-a-z0-9_]*\$"

From adduser man page:

      --force-badname
               By default, user and group names are checked against the 
config‐
               urable regular expression NAME_REGEX  (or 
NAME_REGEX_SYSTEM  if
              --system is specified) specified in the configuration 
file. This
              option forces adduser and addgroup to apply only  a  weak 
 check
              for validity of the name.

Thanks
--Rich

Message #20 received at 705483@bugs.debian.org (full text, mbox, reply):

From: James Carter <james.carter@bytemark.co.uk>

To: 705483@bugs.debian.org

Subject: Re: Bug#705483: xfsprogs: xfs_quota misinterprets usernames with leading digits

Date: Tue, 16 Apr 2013 09:17:21 +0100

On 15/04/13 17:07, Rich Johnston wrote:
>
> I don't think this is a bug, username must begin with a character 
> (unless you created the user using NIS or adduser --force-badname).

My understanding that this is a recommendation rather than a 
requirement. useradd(8) has the following to say:

       On Debian, the only constraints are that usernames must neither 
start
       with a dash ('-') nor contain a colon (':') or a whitespace 
(space: '
       ', end of line: '\n', tabulation: '\t', etc.). Note that using a 
slash
       ('/') may break the default algorithm for the definition of the 
user's
       home directory.

In any case, I'd still consider it a bug that trailing non-numeric 
characters were just silently ignored.

-- 
James Carter                                           Bytemark Hosting
                                             http://www.bytemark.co.uk/
                                              tel: +44 (0) 1904 890 890

Message #25 received at 705483@bugs.debian.org (full text, mbox, reply):

From: Rich Johnston <rjohnston@sgi.com>

To: James Carter <james.carter@bytemark.co.uk>, <705483@bugs.debian.org>

Subject: Re: Bug#705483: xfsprogs: xfs_quota misinterprets usernames with leading digits

Date: Tue, 16 Apr 2013 07:29:48 -0500

On 04/16/2013 03:17 AM, James Carter wrote:
> On 15/04/13 17:07, Rich Johnston wrote:
>>
>> I don't think this is a bug, username must begin with a character
>> (unless you created the user using NIS or adduser --force-badname).
>
> My understanding that this is a recommendation rather than a
> requirement. useradd(8) has the following to say:
>
>         On Debian, the only constraints are that usernames must neither
> start
>         with a dash ('-') nor contain a colon (':') or a whitespace
> (space: '
>         ', end of line: '\n', tabulation: '\t', etc.). Note that using a
> slash
>         ('/') may break the default algorithm for the definition of the
> user's
>         home directory.
>
> In any case, I'd still consider it a bug that trailing non-numeric
> characters were just silently ignored.
>

Interesting I was not aware of the Debian difference.  My understanding 
was that usernames with leading digits would have trouble with other 
utilities on other versions of Unix and flavors of Linux as they would 
interpret the username as numeric UID.  I was able to create a user with 
leading digits and trailing alpha characters using vipw.  Because  chown 
works using this username, we will look into fixing this bug.  Thanks 
for pointing it out.

--Rich

Message #30 received at 705483@bugs.debian.org (full text, mbox, reply):

From: Rich Johnston <rjohnston@sgi.com>

To: James Carter <james.carter@bytemark.co.uk>, <705483@bugs.debian.org>

Cc: <submit@bugs.debian.org>

Subject: Re: Bug#705483: xfsprogs: xfs_quota misinterprets usernames with leading digits

Date: Tue, 23 Apr 2013 08:02:05 -0500

James,

The following commit will resolve the issue.

Thanks
--Rich

commit fd537fc50eeade63bbd2a66105f39d04a011a7f5
Author: Rich Johnston <rjohnston@sgi.com>
Date:   Mon Apr 22 17:32:05 2013 +0000

    xfsprogs: xfs_quota allow user or group names beginning with digits

    xfs_quota does not properly parse users or groups that begin with a 
number.
    Only call atoi when user or group consists of digits only.

    Signed-off-by: Rich Johnston <rjohnston@sgi.com>
    Reported-by: James Carter <james.carter@bytemark.co.uk>
    Reviewed-by: Eric Sandeen <sandeen@redhat.com>
    Reviewed-by: Chandra Seetharaman <sekharan@us.ibm.com>

Message #40 received at 705483-done@bugs.debian.org (full text, mbox, reply):

From: Eric Sandeen <sandeen@sandeen.net>

To: 705483-done@bugs.debian.org

Subject: close

Date: Thu, 5 Jan 2017 17:00:54 -0600

Package: xfsprogs
Version: 4.7.0

A few commits have been made since this bug was filed,
and the problem should be fully resolved as of 4.7.0.

cef37d5 xfs_quota: fully support users and groups beginning with digits
fd537fc xfsprogs: xfs_quota allow user or group names beginning with digits
1d9d570 xfs_quota: fix input of a projectid which starts whith a digit

Send a report that this bug log contains spam.