Message ID | 20200729205117.2925113-4-adhemerval.zanella@linaro.org |
---|---|
State | Superseded |
Headers |
Return-Path: <libc-alpha-bounces@sourceware.org> X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 3244F3860C3C; Wed, 29 Jul 2020 20:51:30 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 3244F3860C3C DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1596055890; bh=1VstSp+PYky8lb8Ew4H/gdqq1r/9rvm5db2xWl8TAcg=; h=To:Subject:Date:In-Reply-To:References:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=tEo6ZKncO3HUHocSgxSvQgkvmW8fMp3Kd6H3jXLVxPC0clFOyaOm7ECWZt1t7soJC uvYtMeCD2oZYpNFOzia2aoqef6WAFRasi0QWeCa2r6N0mXIGKiwluf2CCMQOQCENEJ 8OtfwhKyZTwAMxjdkAT9KNkVf+KzDlT3LM2p8ZQ8= X-Original-To: libc-alpha@sourceware.org Delivered-To: libc-alpha@sourceware.org Received: from mail-qt1-x844.google.com (mail-qt1-x844.google.com [IPv6:2607:f8b0:4864:20::844]) by sourceware.org (Postfix) with ESMTPS id B8C7F3851C01 for <libc-alpha@sourceware.org>; Wed, 29 Jul 2020 20:51:27 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org B8C7F3851C01 Received: by mail-qt1-x844.google.com with SMTP id k18so18718238qtm.10 for <libc-alpha@sourceware.org>; Wed, 29 Jul 2020 13:51:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=1VstSp+PYky8lb8Ew4H/gdqq1r/9rvm5db2xWl8TAcg=; b=ekKDGGzxiZKzkkXsnfQc2bDc2sdp3Qri4S/R/sjX+fajeGe3qIC4H0iRGE5uk9kiEc ZxJYYmDRKryLazkEEJ1unzs7Jc7hQfuimujLcHOLp6ZifdxvEDhLN/S04CS7gUceenwt N8qBFeVumd6HEnPZ5zcaPUl/UqABhSOJFV6v0qaVkg84k+J9adovaKD7crUt/tuK3tTP ds6gTWaWIAEM0t3DL7VbGCWC3xJzc6UQatylbaAffUOlkrrnQfmkQRT2ljaiGaqNOiTX D7aAR05wB0nB74Xy3slC3w1dIh3kQjvH5dXfROmZVSKn36NDH8MtyqUKSoLDLOJiRarB GlCQ== X-Gm-Message-State: AOAM532MIfuNWdTwt1HqkVx5YiUfOi8rH0IwenNpljZjYETgVAMk/q2H ENu+LQXtoZYtXBaYcJTpG9kv6km67dI= X-Google-Smtp-Source: ABdhPJzmJQfpmHYSw2fWZaaokSlXLV08+Iz5cNrn2fjFYkWo8N35JnvIczOycEoL4+Um/MqYAioMcg== X-Received: by 2002:ac8:7046:: with SMTP id y6mr206190qtm.329.1596055887166; Wed, 29 Jul 2020 13:51:27 -0700 (PDT) Received: from localhost.localdomain ([177.194.48.209]) by smtp.googlemail.com with ESMTPSA id v58sm2827230qtj.56.2020.07.29.13.51.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 29 Jul 2020 13:51:26 -0700 (PDT) To: libc-alpha@sourceware.org Subject: [PATCH 4/5] login: User 64-bit time on struct lastlog Date: Wed, 29 Jul 2020 17:51:16 -0300 Message-Id: <20200729205117.2925113-4-adhemerval.zanella@linaro.org> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20200729205117.2925113-1-adhemerval.zanella@linaro.org> References: <20200729205117.2925113-1-adhemerval.zanella@linaro.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-13.9 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, KAM_SHORT, RCVD_IN_DNSWL_NONE, 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 <libc-alpha.sourceware.org> List-Unsubscribe: <https://sourceware.org/mailman/options/libc-alpha>, <mailto:libc-alpha-request@sourceware.org?subject=unsubscribe> List-Archive: <https://sourceware.org/pipermail/libc-alpha/> List-Post: <mailto:libc-alpha@sourceware.org> List-Help: <mailto:libc-alpha-request@sourceware.org?subject=help> List-Subscribe: <https://sourceware.org/mailman/listinfo/libc-alpha>, <mailto:libc-alpha-request@sourceware.org?subject=subscribe> From: Adhemerval Zanella via Libc-alpha <libc-alpha@sourceware.org> Reply-To: Adhemerval Zanella <adhemerval.zanella@linaro.org> Cc: Alistair Francis <alistair.francis@wdc.com> Errors-To: libc-alpha-bounces@sourceware.org Sender: "Libc-alpha" <libc-alpha-bounces@sourceware.org> |
Series |
[1/5] login: Consolidate utmp and utmpx headers
|
|
Commit Message
Adhemerval Zanella Netto
July 29, 2020, 8:51 p.m. UTC
It is not used directly on any symbol, so there is no need to add compat ones. --- bits/struct_lastlog.h | 4 +-- .../sysv/linux/s390/bits/struct_lastlog.h | 35 ------------------- 2 files changed, 2 insertions(+), 37 deletions(-) delete mode 100644 sysdeps/unix/sysv/linux/s390/bits/struct_lastlog.h
Comments
s/User/Use/ Andreas.
On Jul 29 2020, Adhemerval Zanella via Libc-alpha wrote: > It is not used directly on any symbol, so there is no need to add > compat ones. struct lastlog is an external type, describing the format of /var/log/lastlog. Andreas.
On 29/07/2020 18:14, Andreas Schwab wrote: > On Jul 29 2020, Adhemerval Zanella via Libc-alpha wrote: > >> It is not used directly on any symbol, so there is no need to add >> compat ones. > > struct lastlog is an external type, describing the format of > /var/log/lastlog. > Right, so which would be best way to handle this transition? My idea would to be approach to consumers, shadow-utils developers for instance, and state the desirable to make glibc y2038 proof and why this interfaces need to be changed.
* Adhemerval Zanella via Libc-alpha: > On 29/07/2020 18:14, Andreas Schwab wrote: >> On Jul 29 2020, Adhemerval Zanella via Libc-alpha wrote: >> >>> It is not used directly on any symbol, so there is no need to add >>> compat ones. >> >> struct lastlog is an external type, describing the format of >> /var/log/lastlog. >> > > Right, so which would be best way to handle this transition? My idea > would to be approach to consumers, shadow-utils developers for instance, > and state the desirable to make glibc y2038 proof and why this interfaces > need to be changed. Sounds reasonable. We also have a security bug that is related to direct access to these files: <https://sourceware.org/bugzilla/show_bug.cgi?id=24492> If we need to mediate access for format translation, maybe this can be addressed at the same time? Thanks, Florian
On Thu, 30 Jul 2020, Florian Weimer via Libc-alpha wrote: > Sounds reasonable. We also have a security bug that is related to > direct access to these files: > > <https://sourceware.org/bugzilla/show_bug.cgi?id=24492> > > If we need to mediate access for format translation, maybe this can be > addressed at the same time? Having different filenames for the new format might be safest, which would naturally go along with having some form of mediation for access to utmp / wtmp / lastlog.
On 30/07/2020 13:19, Florian Weimer wrote: > * Adhemerval Zanella via Libc-alpha: > >> On 29/07/2020 18:14, Andreas Schwab wrote: >>> On Jul 29 2020, Adhemerval Zanella via Libc-alpha wrote: >>> >>>> It is not used directly on any symbol, so there is no need to add >>>> compat ones. >>> >>> struct lastlog is an external type, describing the format of >>> /var/log/lastlog. >>> >> >> Right, so which would be best way to handle this transition? My idea >> would to be approach to consumers, shadow-utils developers for instance, >> and state the desirable to make glibc y2038 proof and why this interfaces >> need to be changed. > > Sounds reasonable. We also have a security bug that is related to > direct access to these files: > > <https://sourceware.org/bugzilla/show_bug.cgi?id=24492> > > If we need to mediate access for format translation, maybe this can be > addressed at the same time? I think BZ#24492 is another issue and one that is not easily fixed without some changes on the utmp-file.c internals. The utmp/utmpx files are read by the ut{x} functions and used on programs such as 'who', and to fully avoid possible F_SETLKW deadlocks the write must synchronize using a file not accessible by normal users. The alarm trick mitigates the deadlock issue, but it does not help with the fact the log entry is not generated. The bug report suggestion of using a extra file to act as the lock for write synchronization might be a better option. Another possibility is to move to use a daemon broker to actually operate on utmp/utmpx, but I also think it is out of the scope. I am inclined of using the extra lock file, thoughts?
On 30/07/2020 15:54, Joseph Myers wrote: > On Thu, 30 Jul 2020, Florian Weimer via Libc-alpha wrote: > >> Sounds reasonable. We also have a security bug that is related to >> direct access to these files: >> >> <https://sourceware.org/bugzilla/show_bug.cgi?id=24492> >> >> If we need to mediate access for format translation, maybe this can be >> addressed at the same time? > > Having different filenames for the new format might be safest, which would > naturally go along with having some form of mediation for access to utmp / > wtmp / lastlog. > The different filename sound slike a strategy and I understand that the idea would also to use new versions for the utmp/utmpx symbols. What about the compatibility symbols, should them be built on top of the new ABI and access the newer files or use the old format and access the old filenames? As for lastlog, I think it would be feasible to provide a API to mediate the file access as a GNU extension.
On Thu, 30 Jul 2020, Adhemerval Zanella via Libc-alpha wrote: > The different filename sound slike a strategy and I understand that the idea > would also to use new versions for the utmp/utmpx symbols. What about the > compatibility symbols, should them be built on top of the new ABI and access > the newer files or use the old format and access the old filenames? I suppose that gets into questions about programs explicitly using utmpname. If a program using the old symbol versions called utmpname explicitly with some filename, that's probably the name of a file in the old format. But if it doesn't call utmpname, either you can access the old files in the old format and not get current data, or the new files in the new format and convert.
Hi Adhemerval, > It is not used directly on any symbol, so there is no need to add > compat ones. > --- > bits/struct_lastlog.h | 4 +-- > .../sysv/linux/s390/bits/struct_lastlog.h | 35 > ------------------- 2 files changed, 2 insertions(+), 37 deletions(-) > delete mode 100644 sysdeps/unix/sysv/linux/s390/bits/struct_lastlog.h > > diff --git a/bits/struct_lastlog.h b/bits/struct_lastlog.h > index 122a44abd0..6882015d7c 100644 > --- a/bits/struct_lastlog.h > +++ b/bits/struct_lastlog.h > @@ -24,8 +24,8 @@ > previous logins. */ > struct lastlog > { > -#if __WORDSIZE_TIME64_COMPAT32 > - int32_t ll_time; > +#if __TIMESIZE != 64 > + int64_t ll_time; Maybe __time64_t would fit better here? > #else > __time_t ll_time; > #endif Reviewed-by: Lukasz Majewski <lukma@denx.de> > diff --git a/sysdeps/unix/sysv/linux/s390/bits/struct_lastlog.h > b/sysdeps/unix/sysv/linux/s390/bits/struct_lastlog.h deleted file > mode 100644 index 2fa409aeec..0000000000 > --- a/sysdeps/unix/sysv/linux/s390/bits/struct_lastlog.h > +++ /dev/null > @@ -1,35 +0,0 @@ > -/* The 'struct lastlog' type. > - Copyright (C) 2020 Free Software Foundation, Inc. > - This file is part of the GNU C Library. > - > - The GNU C Library is free software; you can redistribute it and/or > - modify it under the terms of the GNU Lesser General Public > - License as published by the Free Software Foundation; either > - version 2.1 of the License, or (at your option) any later version. > - > - The GNU C Library is distributed in the hope that it will be > useful, > - but WITHOUT ANY WARRANTY; without even the implied warranty of > - MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > - Lesser General Public License for more details. > - > - You should have received a copy of the GNU Lesser General Public > - License along with the GNU C Library; if not, see > - <https://www.gnu.org/licenses/>. */ > - > -#ifndef _UTMP_H > -# error "Never include <bits/struct_lastlog.h> directly; use > <utmp.h> instead." -#endif > - > -/* The structure describing an entry in the database of > - previous logins. */ > -struct lastlog > - { > -#if __WORDSIZE == 32 > - int64_t ll_time; > -#else > - __time_t ll_time; > -#endif > - char ll_line[UT_LINESIZE]; > - char ll_host[UT_HOSTSIZE]; > - }; > - Best regards, Lukasz Majewski -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma@denx.de
diff --git a/bits/struct_lastlog.h b/bits/struct_lastlog.h index 122a44abd0..6882015d7c 100644 --- a/bits/struct_lastlog.h +++ b/bits/struct_lastlog.h @@ -24,8 +24,8 @@ previous logins. */ struct lastlog { -#if __WORDSIZE_TIME64_COMPAT32 - int32_t ll_time; +#if __TIMESIZE != 64 + int64_t ll_time; #else __time_t ll_time; #endif diff --git a/sysdeps/unix/sysv/linux/s390/bits/struct_lastlog.h b/sysdeps/unix/sysv/linux/s390/bits/struct_lastlog.h deleted file mode 100644 index 2fa409aeec..0000000000 --- a/sysdeps/unix/sysv/linux/s390/bits/struct_lastlog.h +++ /dev/null @@ -1,35 +0,0 @@ -/* The 'struct lastlog' type. - Copyright (C) 2020 Free Software Foundation, Inc. - This file is part of the GNU C Library. - - The GNU C Library is free software; you can redistribute it and/or - modify it under the terms of the GNU Lesser General Public - License as published by the Free Software Foundation; either - version 2.1 of the License, or (at your option) any later version. - - The GNU C Library is distributed in the hope that it will be useful, - but WITHOUT ANY WARRANTY; without even the implied warranty of - MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU - Lesser General Public License for more details. - - You should have received a copy of the GNU Lesser General Public - License along with the GNU C Library; if not, see - <https://www.gnu.org/licenses/>. */ - -#ifndef _UTMP_H -# error "Never include <bits/struct_lastlog.h> directly; use <utmp.h> instead." -#endif - -/* The structure describing an entry in the database of - previous logins. */ -struct lastlog - { -#if __WORDSIZE == 32 - int64_t ll_time; -#else - __time_t ll_time; -#endif - char ll_line[UT_LINESIZE]; - char ll_host[UT_HOSTSIZE]; - }; -