Re: utmps: ut_id field gets truncated

From: Amin Rasooli <ARasooli_at_cccis.com>
Date: Mon, 12 Apr 2021 14:27:32 +0000

Hi,

How can I opt-out if the subscription to this email chain? I don’t think it is related to me.

Regards,
Amin Rasooli
Associate Director, AI Enablement and AI Ops
Phone: 312.229.2540
 

On 4/11/21, 11:51 PM, "skaware_at_list.skarnet.org on behalf of Xavier Stonestreet" <skaware_at_list.skarnet.org on behalf of xstonestreet_at_gmail.com> wrote:

    THIS EMAIL WAS SENT BY SOMEONE OUTSIDE OF CCC. USE CAUTION BEFORE CLICKING ON ANY LINKS.


    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.

    Thanks.

Received on Mon Apr 12 2021 - 14:27:32 UTC