From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS3215 2.6.0.0/16 X-Spam-Status: No, score=-4.2 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [IPv6:2620:52:3:1:0:246e:9693:128c]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 328B01F5AE for ; Tue, 27 Apr 2021 12:30:50 +0000 (UTC) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 365BA3894C1E; Tue, 27 Apr 2021 12:30:25 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 365BA3894C1E DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1619526625; bh=godn88kSfBJIBUtISwcYQOVw6hWo3o1Ei7KTFnlFxGQ=; h=To:Subject:References:Date:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To: From; b=wE/BFP6SaQALGyUEOr0nnilAdJQ7l7WR1NgJiBa/3toaW5IAoB89sJLoZwAYokO1L Igndkl59slwT7cPUv2qt42DixRDHdvnoI9f27KaiIuvLMEr02dBD8tBYchmpyGPI+h r0ojJd4+EuYAMdGceT2wshmIK65vTd+tyCd2Kk+0= Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by sourceware.org (Postfix) with ESMTP id 1A89C3894C1E for ; Tue, 27 Apr 2021 12:30:22 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 1A89C3894C1E Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-393-IW5dBYvgPSuIZEMyepo3Ew-1; Tue, 27 Apr 2021 08:30:19 -0400 X-MC-Unique: IW5dBYvgPSuIZEMyepo3Ew-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id A9A94804034; Tue, 27 Apr 2021 12:30:18 +0000 (UTC) Received: from oldenburg.str.redhat.com (ovpn-113-20.ams2.redhat.com [10.36.113.20]) by smtp.corp.redhat.com (Postfix) with ESMTPS id CD84119704; Tue, 27 Apr 2021 12:30:17 +0000 (UTC) To: Adhemerval Zanella via Libc-alpha Subject: Re: [PATCH 20/52] login: Add 64-bit time support to utmp/utmpx References: <20210305201518.798584-1-adhemerval.zanella@linaro.org> <20210305201518.798584-21-adhemerval.zanella@linaro.org> Date: Tue, 27 Apr 2021 14:30:45 +0200 In-Reply-To: <20210305201518.798584-21-adhemerval.zanella@linaro.org> (Adhemerval Zanella via Libc-alpha's message of "Fri, 5 Mar 2021 17:14:46 -0300") Message-ID: <87zgxjnc3u.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Florian Weimer via Libc-alpha Reply-To: Florian Weimer Errors-To: libc-alpha-bounces@sourceware.org Sender: "Libc-alpha" * Adhemerval Zanella via Libc-alpha: > The new struct has the same size for 32-bit and 64-bit architecture with > two main differences compared to the 32-bit time one: I think we should deprecate the interfaces instead. Due to a local denial-of-service vulnerability (bug 24492), we would have to switch to a daemon. However, the wtmp logging is rather useless these days because the main key is ut_id, the =E2=80=9Cterminal name suffix=E2=80=9D (so presumably S0 = for the first serial console). But most terminals are pseudo-terminals today, and it is fairly meaningless which user was logged on on which pseudo-terminal. glibc offers an additional lookup procedure with unique ut_line keys as an extension. But even if meaningful keys are used there (such as host names), another issue appears: the interface is designed in such a way that the set of lookup keys must be very small because old entries are never expired, only overwritten if the lookup key is used again. The challenge with the present interface is that applications need to come up with a lookup key that is unique, meaningful, and will be reused quickly in case the session terminates. Historically, it was possible to use the PID (and vfsftpd does that), but the PID limit is gone on some distributions, and the PID in the index leads to essentially unbounded utmp file growth. The interface was fine when a system had a few fixed terminal lines that weren't equivalent. But I think it's mostly useless today. Thanks, Florian