>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
Received on Tue Apr 13 2021 - 01:11:03 UTC