> A big part of the problem is L_cuserid from > <stdio.h>, which is a > preprocessor symbol with the value 9 (8 + 1 for NUL > byte terminator). > That's been around forever, can't really go away > (AFAIK), and once a program > that uses that has been compiled, it can't be changed > without recompiling > it. That might not be a problem for Solaris code, > which could be changed > to have a higher limit, but there could be all sorts > of programs from freeware > to commercial that run on Solaris and will either > truncate or overflow a buffer > if a username is longer than 8 bytes. > > That is, some program will declare an array > char username[L_cuserid]; > hold an account name, and depending on how careful it > is about reading > in the account name, it will either have to truncate > it (which probably won't > give the results you want if the name is longer) or > it will overrun the array > and probably add a bunch of garbage on the end (which > also won't work), > and quite possibly core dump as well. > > So even if it could be guaranteed that everything > that comes with Solaris > could handle longer names, with the need for > backwards compatibility for > existing applications, it might not be possible to > guarantee that _they_ could > handle longer names properly.
I NEED this ability. And I would bet that if you queried your user base, it would be an almost universal complaint. I've been thinking about it and think I may have a way that might work. One caveat, Because I don't know C, am my model that I have constructed in my brain that is based on trial and error may be incomplete or inacurate. Why not introduce a new syscall(?) to dynamically query the username length, where the setting is set by the admin? (Maybe in /etc/system, maybe somewhere else) That way programs have an option of being compiled in a future safe method. New programming guidelines would recommend that developers change to the new methods. The syscall settings default would be set to 8 bytes by default. The old methods with the old settings would still be supported, to maintain binary compatibility. (using truncation in the event of a conflict. the first entry in /etc/passwd that matched the truncated entry would match and return that UID). Once Sun recompiled all the apps to use the new method, they would introduce this into a named release. One other note, changing gid limitation would be done the same way. Actually a similar approach could be done for all baked in system limitations. (Sun could wash it's hands of the deal as long as everything made by Sun used the new dynamic methods, and the default was the old setting.) -brian P.S. - Please fix the communities this should go to, as I am a relatively new participant to Opensolaris. This message posted from opensolaris.org _______________________________________________ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
