[Pkg-shadow-devel] Bug#493230: manpage of adduser/useradd does not mention how long a username can be

[Nicolas François]

On Mon, Aug 11, 2008 at 10:38:10PM +0200, linux4michelle at tamay-dogan.net wrote:
> 
> The GROUPs I am using are
> 
> private:x:1000:
> business:x:1100:michelle.konzack
> development:x:1200:michelle.konzack
> server:x:1400:michelle.konzack
> debian:x:1600:michelle.konzack
> redhat:x:1700:michelle.konzack
> cybercenter:x:1800:michelle.konzack
> omega:x:1900:michelle.konzack
> 
> so noting longer then 16 characters.  I have tested it with:

You tried to add user, ass1234567890123456789012345678901234567890, which
tried to create a group with the same name.
This one has more than 32 characters.

On Debian, the limit for group names is 32 chars (I will fix the manpage).
The naming policy is also very relaxed.

With the recommended policy ([a-z_][a-z0-9_-]*[$]?), this makes something
like 2E+50 possible usernames.
With the Debian relaxed naming policy (^[^-:\s][^:\s]*$), this should be
something like 5E+76 possible usernames.

This might be a problem if the French government want to give a name to
each particles in the Universe (1E+80), but should still be sufficient for
some time for human beings.

Note: You will be limited to 2^64 (2E+19) UIDs anyway.


I think the problem in on your naming policy (abc<decimal number>).
Using hexadecimal numbers (or higher base) could some your issue.

> It seems, "GROUP =< 16" and "USER =< 32".

This was fixed on Debian in 2004. Both user and group names need to be
less than 32 chars. I will update the manpage.

IMHO, the restrictions come from the logging to utmp.
If you want that restriction to be removed, you should indicate more
clearly what you want to do. (and why the 2^64 UID limit is not the real
restriction for your use case).

> Not realy nice,  if  you  can
> imagine, I have an dictionary attack on one of my mail server  with  now
> over 86.000.000 different combinations of alpha-numeric  logins  in  the
> last 4 years.  (The server is used in the french Governement  :-/ )

I don't understand the point.

86.000.000 is about 3,3E-41% of all the possible combinations.
If the attack continues at the same speed, this still give you about
100000000000000000000000000000000000000000000 years until they cover all
the combinations.

I will fix that bug after fixing the groupadd manpage and adding the limit
to the useradd manpage, but I don't see the need for any other changes.

Best Regards,
-- 
Nekral