From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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) From: Florian Weimer 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-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org 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: , X-List-Received-Date: Tue, 27 Apr 2021 12:30:23 -0000 * 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