From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by sourceware.org (Postfix) with ESMTPS id DC2A83858426 for ; Tue, 14 Feb 2023 09:26:15 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org DC2A83858426 Authentication-Results: sourceware.org; dmarc=fail (p=quarantine dis=none) header.from=suse.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=suse.de Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out1.suse.de (Postfix) with ESMTP id 003EA21A67 for ; Tue, 14 Feb 2023 09:26:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1676366775; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=y3nEwDMMY5OHl5OhDzm/bet2GocNi/uh2FzuKU732ZQ=; b=RktsejIZDk52vE0rdfgCCvW3Pt/513gBK/TAgZlQ7RZrNJAwUPssBtRmMyivpuqKzBcnKY zXaeZT6d3EocX6v20J2nrHghQFS0EXSMAjayMp8twsOsBv3enGI6pigT1dMMMGLGC/lxam Jklm7vg9cFtmzZWJop1j68x4GVuDyfw= Received: from kukuk-phex.future.suse.de (unknown [10.162.233.67]) by relay2.suse.de (Postfix) with ESMTP id EB6C42C141 for ; Tue, 14 Feb 2023 09:26:14 +0000 (UTC) Received: by kukuk-phex.future.suse.de (Postfix, from userid 358) id DD5D560032; Tue, 14 Feb 2023 10:26:14 +0100 (CET) Date: Tue, 14 Feb 2023 10:26:14 +0100 From: Thorsten Kukuk To: Thorsten Kukuk via Libc-alpha Subject: Re: 64-bit time_t and __WORDSIZE_TIME64_COMPAT32 Message-ID: <20230214092614.GA700@suse.com> References: <20230208091821.GA2282@suse.com> <0869a6f98f29405eb431f63db593c490@DB6PR04MB3255.eurprd04.prod.outlook.com> <20230208101125.GA5099@suse.com> <20230208102225.GA5543@suse.com> <7485b79473614eaa994d3ea79c91629a@DB6PR04MB3255.eurprd04.prod.outlook.com> <20230208103819.GA6177@suse.com> <901005ca-640f-3a8f-a199-c1374f3cf141@linaro.org> <20230214082409.GA29974@suse.com> <3230d2f8fa214c268cba52e699c14ae2@DB6PR04MB3255.eurprd04.prod.outlook.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <3230d2f8fa214c268cba52e699c14ae2@DB6PR04MB3255.eurprd04.prod.outlook.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-Spam-Status: No, score=-1.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,KAM_NUMSUBJECT,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Tue, Feb 14, Florian Weimer wrote: > * Thorsten Kukuk via Libc-alpha: > > So the main consumer of utmp is glibc itself: getlogin()/getlogin_r() > > Is there any idea how to replace that, if utmp/wtmp gets deprecated? > > We use /proc/self/loginuid already, and try to resolve that UID using > NSS. We still have fallback to __getutline_r. I think it would be > really helpful if you could discover why that fallback is used. I would > have thought it's dead code. > > Is it because /proc/self/loginuid is missing, or because NSS fails for > some reason? If it's about /proc/self/loginuid, maybe we can look at > the owner of /dev/tty instead. I made an half-automatic analysis of the binaries and corresponding source code and it seems I looked at the wrong sysdeps file in the glibc sources :( I didn't checked at runtime as I never know if I hit the correct execution path or not. Sorry, with the current glibc implementation we should be fine, so I will create bug reports against the projects who implemented their own getlogin() function based on utmp. Thanks, I will fix my document. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect, Future Technologies SUSE Software Solutions Germany GmbH, Frankenstraße 146, 90461 Nuernberg, Germany Managing Director: Ivo Totev, Andrew Myers, Andrew McDonald, Martje Boudien Moerman (HRB 36809, AG Nürnberg)