+1, thanks for the great background research on this. (Even with the
typo in the title.)
- Garrett
On 05/20/10 09:01 AM, Darren J Moffat wrote:
Template Version: @(#)sac_nextcase 1.70 03/30/10 SMI
This information is Copyright (c) 2010, Oracle and/or its affiliates. All
rights reserved.
1. Introduction
1.1. Project/Component Working Name:
Username legnth
1.2. Name of Document Author/Supplier:
Author: Darren Moffat
1.3 Date of This Document:
20 May, 2010
4. Technical Description
Solaris currently documents a maximum username length of 8 characters
in passwd(4).
Other Operating Systems don't have such a small limit. In fact Solaris
mostly works and has for quite some time with usernames upto 32
characters.
The 8 character limit is manifest in three places
1) the LOGNAME_MAX constant in<limits.h> (8)
2) L_cuserid in stdio.h (when __EXTENSIONS__) is defined (9)
This symbol is deprecated for XPG6 / SUSv3 onwards.
3) getconf _POSIX_LOGIN_NAME_MAX / LOGIN_NAME_MAX (9)
The OpenGroup limits.h documentation says that LOGIN_NAME_MAX returns
the number maximum number length of a login name and that _POSIX_LOGIN_NAME_MAX
is the minumum acceptable value. That implies that they need not be
the same.
This case changes so that we have:
1) the LOGNAME_MAX constant in<limits.h> (32)
2) L_cuserid in stdio.h (when __EXTENSIONS__) is defined (33)
This symbol is deprecated for XPG6 / SUSv3 onwards.
3) getconf _POSIX_LOGIN_NAME_MAX (9)
4) getconf LOGIN_NAME_MAX (33)
Going beyond 32 characters for the username is more complex since
utmpx(4) is defined to have the ut_user/ut_name field as 32 characters,
changing this would very likely break consumers of getutexent(3C) even
if they were all able to be recompiled.
This case proposes to change the documented limit in passwd(4) from 8
to 32 and declare that anything not implementing that is a bug. This
case does not require that any part of the system enforce 32 as an
upper limit (though some may), only that it is a bug that providing
it doesn't break standards if they enforce the legacy behaviour of 8
and that they accept and use 32 character long usernames. "Work" does
not require that all output fields that "line up" with 8 character long
usernames still "line up" when using 32 character long usernames.
Ideally code should use sysconf to lookup LOGIN_NAME_MAX but there is
also a lot of exsting that derives the size using something like this:
(sizeof (((struct utmpx *)0)->ut_name))
The method for fixing utilities that are currently restricted to 8
character usernames is outside the scope of the ARC case and is really
an issue for the codereviewers and CRT advocates. Though it is highly
recommended that "32" not be hardcoded into a local constant but
instead either LOGNAME_MAX from<limits.h> be used or if possible
sysconf(3C), the method of using the ut_name field is acceptable
particularly if it means minimal code change.
When this case integrates the following bugs will be fixed
4169241 LOGNAME_MAX should be greater than 8.
4033673 passwd cannot be changed if login id is longer than 8 characters
4109819 user names longer than 8 characters needed
4431427 *useradd* useradd(1M) should not complain about a username longer
than 8 char
4435330 *logname* logname prints out only part of long login name
4909548 system tools allow to create usernames> 8 chars.
4927530 *w* w(1) truncates usernames to 8 chars
6551524 su truncates LOGNAME for long usernames.
6627292 *cron* confused about username lengths
6819489 *su* sulog source username truncated to 8 chars but destination name
not
6866548 last command does not support usernames longer than 8 characters
6. Resources and Schedule
6.4. Steering Committee requested information
6.4.1. Consolidation C-team Name:
ON
6.5. ARC review type: FastTrack
6.6. ARC Exposure: open
_______________________________________________
opensolaris-arc mailing list
[email protected]
