Just FYI:
I can confirm what Bill points out below. Solaris naming services does not
intentionally impose a limits on the length of username (or any other
variable
length strings like gecos etc.). NIS currently still has a 4k buffer
max, so
a NIS passwd entry total length has that upwards boundary. Also we do
impose
another max buffer size at 128K, such as when you do a getpwnam_r or
similar API call and are using caching (nscd). Beyond that things like
files
line length or LDAP uid=name are bounded by outside forces such as the
maximum size of a vi line buffer or a specific LDAP schema/server limit.
Anything (in name services) contradicting this is considered a name
services bug.
Doug.
On 05/20/10 11:16 PM, Bill Sommerfeld wrote:
On 05/20/10 19:57, James Carlson wrote:
Of course, I welcome the change, and I'd be quite surprised if Informix
up 'n fell over on it. It's about danged time. I'm sure Mr. Sommerfe
and the Legions of the Truncated Surnames will agree. ;-}
Indeed.
Where possible, I've been running with a 10-character username in
/etc/passwd since I started at sun in 2000 ; I've also verified that
this works in NIS. I've run into surprisingly few bugs. More than a
few deltas in the teamware/SCCS sources used for solaris 10 and
earlier were created by the user "sommerfeld".
Nothing in solaris 8 or later (and I haven't verified earlier
releases) prevents an application from seeing a
longer-than-LOGNAME_MAX string from pwd.pw_name.
What's more, administrators who use "useradd" to add a user with a
long name will see a warning message, but the user will be added to
/etc/passwd file anyway.
So nothing compiled into the code enforces an 8-character maximum
today if a system administrator chooses to use longer usernames; all
that really remains of the limit is the attractive nuisance of
LOGNAME_MAX.
One alternative that I haven't fully explored is to (conditionally or
unconditionally) delete LOGNAME_MAX from limits.h, forcing
applications to rely on the dynamic size returned by sysconf(). We
have long recognized an exception to the backwards compatibility
requirements when an interface contains an inherent risk of data
corruption, and that seems to be evident here; given that an
alternative interface exists (sysconf(_SC_LOGIN_NAME_MAX)), and also
given the prevalence of other systems which don't bother to define
LOGNAME_MAX, this may well be a safer path.
- Bill
_______________________________________________
opensolaris-arc mailing list
[email protected]
