One more report, sorry...

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.

This is a problem for example with ssh (OpenSSH to be precise, I don't
know what Dropbear does) and pseudo-terminals. OpenSSH uses the last 4
characters of the pty as the id field. So for example if one user is
connected to /dev/pts/0, the id used for utmp is "ts/0". If another
user is connected to /dev/pts/1, the id is "ts/1". And so forth.

With the truncation glitch both entries are recorded with id "ts/".
Which should become an issue when it comes to searching for the right
record when one of the users logs out and utmp is updated, since they
both collide. And yet for some unfathomable reason the correct record
gets found and updated as per my limited testing.

I looked briefly at the code, client and server-side, but didn't see
anything obvious. There must be a simple off-by-1 calculation or
indexing error somewhere.


Reply via email to