As the title says. If you put "1234" in the ut_field of the utmpx, call pututxline() and then read it back, you get "123" back. An od(1) dump of the utmp file shows that what is stored is 1, 2, 3 and \0.
Yup. Again, it comes down to a lack of specification. https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/utmpx.h.html says that ut_user, ut_id and ut_line are all char[]. Linux clients seem to interpret them as strings, so I treated them as strings, in the safest way I could: making sure to add terminating null characters at the end, just in case. (This is not defensive programming, this is sanitization: the data is provided by some user and ends up in a global database, which may then be read by some other user. Sanitizing it is good practice.) But from what you said, OpenSSH does not treat ut_id as a string. It treats it as an array of 4 characters, that does not need to be null-terminated. This is permitted by the specification, which describes ut_id as "Unspecified initialization process identifier" (thanks, spec, very helpful), but goes against the principle of least surprise since it treats ut_user and ut_line as strings. Or maybe it does not and it's just that user and line names are always short enough to never cause any problem. Anyway, I changed utmps so that ut_id - and also ut_user and ut_line, for consistency - are treated as char arrays, not as null-terminated strings. In other words, I reverted to GIGO. If a client puts in a non-null- terminated array and another client expects a null-terminating string and makes the mistake of trusting data coming from the utmp database, then hilarity will ensue. Too bad, they can't have it both ways. Please test the latest git head and tell me if it's working for you. -- Laurent
