[...] > 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).
Unless something has changed, isn't NIS also subject to the ndbm(3c) limit: "The sum of the sizes of a key/content pair must not exceed the internal block size (currently 1024 bytes). Moreover all key/content pairs that hash together must fit on a single block." (I think at one time this caused incompatibilities with Linux, which did NIS with gdbm or some such underlying storage, that didn't have that limit; in which case, there could be problems if the NIS master was on Linux and a NIS slave (replica) was on Solaris, because the master could store records or combinations of records that blew out of that unpredictable limit on the slaves.) And even if that weren't a 1KB limit, there's still NSS_LINELEN_PASSWD, which is only NSS_BUFSIZ (1024), as compared to say NSS_LINELEN_GROUP (which is NSS_BUFSIZ*8, presumably to allow for lots of group members). Humanly reasonable is probably 40 characters or less, although I can find evidence of full names extending well beyond that. But in any event, utmpx ut_user is 32 bytes. That's the same on Linux I think, so that would give compatibility with them. (It looks to me like with Windows the limit depends on the oldest interoperating version, and could go as high as 256 characters, albeit in a limit character set.) Remember though that 32 bytes could also be worst case of 8 characters of UTF-8, assuming one allows printable UTF-8 other than colon or space. And longer than eight character names will make ls (and similar) output ugly, unless it truncates them. So there's standards compliance, there's interoperability, and there's what won't look ugly or have undesirable results even for "correct" code. Hopefully all of those issues will be addressed (and documented). -- This message posted from opensolaris.org _______________________________________________ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
