GNU bug report logs - #76876
logname output is often wrong when linked with glibc

Previous Next

Package: coreutils;

Reported by: Nicolas Boos <nicolas.boos <at> wanadoo.fr>

Date: Sat, 8 Mar 2025 23:08:03 UTC

Severity: normal

Done: Pádraig Brady <P <at> draigBrady.com>

Bug is archived. No further changes may be made.

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 76876 in the body.
You can then email your comments to 76876 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-coreutils <at> gnu.org:
bug#76876; Package coreutils. (Sat, 08 Mar 2025 23:08:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Nicolas Boos <nicolas.boos <at> wanadoo.fr>:
New bug report received and forwarded. Copy sent to bug-coreutils <at> gnu.org. (Sat, 08 Mar 2025 23:08:03 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Nicolas Boos <nicolas.boos <at> wanadoo.fr>
To: bug-coreutils <at> gnu.org
Subject: logname output is often wrong when linked with glibc
Date: Sat, 8 Mar 2025 17:46:22 +0100
First test case with logname 9.1 and glibc 2.36:
$ echo $LOGNAME
nicolas
$ logname
nicolas
$ su --login root
$ echo $LOGNAME
root
$ logname
nicolas
$ logname (musl)
root
$ logname (uclibc)
root

Second test case, with a minimal chroot, no /proc and busybox login:
$ echo $LOGNAME
nicolas
$ logname
logname: no login name
$ busybox logname
logname: getlogin: No such file or directory
$ logname (musl)
nicolas
$ logname (uclibc)
nicolas

It seems getlogin() is malfunctioning only with glibc.

The following patch with "equivalent code" fixes the issue:
--- logname.c.orig
+++ logname.c
@@ -71,7 +71,11 @@
 
   /* POSIX requires using getlogin (or equivalent code) and prohibits
      using a fallback technique.  */
-  cp = getlogin ();
+  #if __GLIBC__
+    cp = getenv ("LOGNAME");
+  #else
+    cp = getlogin ();
+  #endif
   if (! cp)
     error (EXIT_FAILURE, 0, _("no login name"));

Adding a permanent fix to gnulib/getlogin.c code might be a better solution.

NB




Information forwarded to bug-coreutils <at> gnu.org:
bug#76876; Package coreutils. (Sat, 08 Mar 2025 23:44:01 GMT) Full text and rfc822 format available.

Message #8 received at 76876 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Nicolas Boos <nicolas.boos <at> wanadoo.fr>
Cc: Gnulib bugs <bug-gnulib <at> gnu.org>, 76876 <at> debbugs.gnu.org
Subject: Re: bug#76876: logname output is often wrong when linked with glibc
Date: Sat, 8 Mar 2025 15:42:51 -0800
[Message part 1 (text/plain, inline)]
On 2025-03-08 08:46, Nicolas Boos via GNU coreutils Bug Reports wrote:
> It seems getlogin() is malfunctioning only with glibc.

It's the other way round: glibc is right (in the sense that it conforms 
to POSIX) and the other two are wrong.

> Adding a permanent fix to gnulib/getlogin.c code might be a better solution.

Any such fix should work around the musl bug. (Gnulib doesn't worry 
about uclibc.)

I expect such a patch would be welcome if someone had the time to write 
and test it. In the meantime I installed the attached to Gnulib, to 
document the incompatibility, which also occurs with getlogin_r.
[0001-getlogin-document-musl-bug.patch (text/x-patch, attachment)]

Information forwarded to bug-coreutils <at> gnu.org:
bug#76876; Package coreutils. (Sun, 09 Mar 2025 09:24:02 GMT) Full text and rfc822 format available.

Message #11 received at 76876 <at> debbugs.gnu.org (full text, mbox):

From: Bruno Haible <bruno <at> clisp.org>
To: Nicolas Boos <nicolas.boos <at> wanadoo.fr>, bug-gnulib <at> gnu.org,
 Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 76876 <at> debbugs.gnu.org
Subject: Re: bug#76876: logname output is often wrong when linked with glibc
Date: Sun, 09 Mar 2025 10:23:02 +0100
[Message part 1 (text/plain, inline)]
Paul Eggert wrote:
> In the meantime I installed the attached to Gnulib, to 
> document the incompatibility, which also occurs with getlogin_r.

These two patches actually work around the bugs.

With this, coreutils should be fine, since it already imports the 'getlogin'
module from gnulib.


2025-03-09  Bruno Haible  <bruno <at> clisp.org>

	getlogin_r: Work around musl bug.
	* lib/getlogin_r.c (getlogin_r): Add implementation for Linux.
	* m4/getlogin_r.m4 (gl_FUNC_GETLOGIN_R): Test whether getlogin_r has the
	musl bug.
	* tests/test-getlogin_r.c (main): Add another test.
	* doc/posix-functions/getlogin_r.texi: Mention the workaround.

2025-03-09  Bruno Haible  <bruno <at> clisp.org>

	getlogin: Work around musl bug.
	* lib/unistd.in.h (getlogin): Consider REPLACE_GETLOGIN.
	* lib/getlogin.c: Change license header to GPL.
	(getlogin): Add implementation for Linux.
	* m4/getlogin.m4 (gl_FUNC_GETLOGIN): Test whether getlogin works.
	* m4/unistd_h.m4 (gl_UNISTD_H_DEFAULTS): Initialize REPLACE_GETLOGIN.
	* modules/unistd-h (Makefile.am): Substitute REPLACE_GETLOGIN.
	* modules/getlogin (Depends-on): Add readutmp.
	(configure.ac): Consider REPLACE_GETLOGIN.
	(License): Change to GPL.
	* tests/test-getlogin.c (main): Add another test.
	* doc/posix-functions/getlogin.texi: Mention the workaround.

[0001-getlogin-Work-around-musl-bug.patch (text/x-patch, attachment)]
[0002-getlogin_r-Work-around-musl-bug.patch (text/x-patch, attachment)]

Information forwarded to bug-coreutils <at> gnu.org:
bug#76876; Package coreutils. (Sun, 09 Mar 2025 11:09:02 GMT) Full text and rfc822 format available.

Message #14 received at 76876 <at> debbugs.gnu.org (full text, mbox):

From: Bruno Haible <bruno <at> clisp.org>
To: Nicolas Boos <nicolas.boos <at> wanadoo.fr>, bug-gnulib <at> gnu.org,
 Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 76876 <at> debbugs.gnu.org
Subject: Re: bug#76876: logname output is often wrong when linked with glibc
Date: Sun, 09 Mar 2025 12:08:38 +0100
I wrote:
> With this, coreutils should be fine, since it already imports the 'getlogin'
> module from gnulib.

Verified by comparing coreutils-9.5 with coreutils-HEAD on Alpine Linux 3.20:

With coreutils-9.5:

$ logname
bruno
$ su -
Password:
# logname
root

Now:

$ logname
bruno
$ su -
Password:
# logname
bruno

Paul, Pádraig: How about adding a coreutils/NEWS entry for this bug fix?

Bruno







Reply sent to Pádraig Brady <P <at> draigBrady.com>:
You have taken responsibility. (Sun, 09 Mar 2025 12:50:02 GMT) Full text and rfc822 format available.

Notification sent to Nicolas Boos <nicolas.boos <at> wanadoo.fr>:
bug acknowledged by developer. (Sun, 09 Mar 2025 12:50:02 GMT) Full text and rfc822 format available.

Message #19 received at 76876-done <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: Bruno Haible <bruno <at> clisp.org>, Nicolas Boos <nicolas.boos <at> wanadoo.fr>,
 bug-gnulib <at> gnu.org, Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 76876-done <at> debbugs.gnu.org
Subject: Re: bug#76876: logname output is often wrong when linked with glibc
Date: Sun, 9 Mar 2025 12:48:49 +0000
On 09/03/2025 11:08, Bruno Haible via Gnulib discussion list wrote:
> I wrote:
>> With this, coreutils should be fine, since it already imports the 'getlogin'
>> module from gnulib.
> 
> Verified by comparing coreutils-9.5 with coreutils-HEAD on Alpine Linux 3.20:
> 
> With coreutils-9.5:
> 
> $ logname
> bruno
> $ su -
> Password:
> # logname
> root
> 
> Now:
> 
> $ logname
> bruno
> $ su -
> Password:
> # logname
> bruno
> 
> Paul, Pádraig: How about adding a coreutils/NEWS entry for this bug fix?

I pushed an update to coreutils NEWS mentioning the fix.
Marking this as done.

thanks!
Pádraig.




Information forwarded to bug-coreutils <at> gnu.org:
bug#76876; Package coreutils. (Sun, 09 Mar 2025 13:46:02 GMT) Full text and rfc822 format available.

Message #22 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Nicolas Boos <nicolas.boos <at> wanadoo.fr>
To: Bruno Haible via GNU coreutils Bug Reports <bug-coreutils <at> gnu.org>
Cc: bug-gnulib <at> gnu.org, Paul Eggert <eggert <at> cs.ucla.edu>,
 Bruno Haible <bruno <at> clisp.org>, 76876 <at> debbugs.gnu.org,
 Rich Felker <dalias <at> libc.org>
Subject: bug#76876: logname output is often wrong when linked with glibc
Date: Sun, 9 Mar 2025 14:43:29 +0100
This page says that the result of the logname command and the LOGNAME
variable must be the same:
https://www.ibm.com/docs/en/aix/7.3?topic=l-logname-command

Thus, getlogin() implementations that use the LOGNAME or login_name
variables such as musl, uclibc or even gnulib WIN32 seems fine.

What to believe?


Anyway, using a UID to get a login name like glibc's getlogin() function
does, we sometimes get incorrect results.

Here is a third test case, allowed by posix:
$ cat /etc/passwd
nicolas:x:1000:2001::/home/nicolas:/bin/bash
claude:x:1000:2002::/home/claude:/bin/zsh

localhost login: claude
Password:
$ echo $LOGNAME
claude
$ logname (glibc)
nicolas
$ logname (musl)
claude
$ logname (uclibc)
claude

I'm not really convinced that these fixes make things better.

NB


> I wrote:
> > With this, coreutils should be fine, since it already imports the 'getlogin'
> > module from gnulib.
> 
> Verified by comparing coreutils-9.5 with coreutils-HEAD on Alpine Linux 3.20:
> 
> With coreutils-9.5:
> 
> $ logname
> bruno
> $ su -
> Password:
> # logname
> root
> 
> Now:
> 
> $ logname
> bruno
> $ su -
> Password:
> # logname
> bruno
> 
> Paul, Pádraig: How about adding a coreutils/NEWS entry for this bug fix?
> 
> Bruno
> 
> 
> 
> 
> 
> 




Information forwarded to bug-coreutils <at> gnu.org:
bug#76876; Package coreutils. (Sun, 09 Mar 2025 13:46:03 GMT) Full text and rfc822 format available.

Information forwarded to bug-coreutils <at> gnu.org:
bug#76876; Package coreutils. (Sun, 09 Mar 2025 16:05:02 GMT) Full text and rfc822 format available.

Message #28 received at 76876 <at> debbugs.gnu.org (full text, mbox):

From: Bernhard Voelker <mail <at> bernhard-voelker.de>
To: 76876 <at> debbugs.gnu.org, P <at> draigBrady.com, nicolas.boos <at> wanadoo.fr
Subject: Re: bug#76876: logname output is often wrong when linked with glibc
Date: Sun, 9 Mar 2025 17:04:09 +0100
Hi Padraig,

On 3/9/25 13:48, Pádraig Brady wrote:
> I pushed an update to coreutils NEWS mentioning the fix.
> Marking this as done.

>    doc: mention logname improvement in NEWS
>
>    * NEWS: Mention the improvement in gnulib commit 90840606.
>    Addresses https://bugs.gnu.org/76876

FWIW: That gnulib commit will only be available with the next
gnulib update in coreutils, obviously.

Have a nice day,
Berny




Information forwarded to bug-coreutils <at> gnu.org:
bug#76876; Package coreutils. (Sun, 09 Mar 2025 18:50:02 GMT) Full text and rfc822 format available.

Message #31 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Bruno Haible <bruno <at> clisp.org>
To: bug-coreutils <at> gnu.org, Nicolas Boos <nicolas.boos <at> wanadoo.fr>
Cc: Paul Eggert <eggert <at> cs.ucla.edu>, bug-gnulib <at> gnu.org, 76876 <at> debbugs.gnu.org,
 Rich Felker <dalias <at> libc.org>
Subject: Re: bug#76876: logname output is often wrong when linked with glibc
Date: Sun, 09 Mar 2025 19:49:15 +0100
Nicolas Boos wrote:
> This page says that the result of the logname command and the LOGNAME
> variable must be the same:
> https://www.ibm.com/docs/en/aix/7.3?topic=l-logname-command

An AIX man page is not a specification for what we run on GNU systems.

> Thus, getlogin() implementations that use the LOGNAME or login_name
> variables such as musl, uclibc or even gnulib WIN32 seems fine.

getlogin() is used for security and auditing purposes, for example,
for recording who has made important system changes as 'root'.

The problem with getenv("LOGNAME") is that it is arbitrarily fakeable.
For some uses, this may be fine. For other uses, it is not. And it's
for the latter that POSIX specified the getlogin() function that
accesses system-internal data structures that are not fakeable.
(If every use-case was happy with getenv("LOGNAME"), there would be
no need for a getlogin() function in POSIX.)

> Anyway, using a UID to get a login name like glibc's getlogin() function
> does, we sometimes get incorrect results.
> 
> Here is a third test case, allowed by posix:
> $ cat /etc/passwd
> nicolas:x:1000:2001::/home/nicolas:/bin/bash
> claude:x:1000:2002::/home/claude:/bin/zsh
> 
> localhost login: claude
> Password:
> $ echo $LOGNAME
> claude
> $ logname (glibc)
> nicolas
> $ logname (musl)
> claude
> $ logname (uclibc)
> claude

Yes, POSIX [1] says "If getlogin() returns a non-null pointer, then that
pointer points to the name that the user logged in under, even if there
are several login names with the same user ID." This can be implemented
on systems like FreeBSD, where the kernel keeps track of the user name
as a string. But on Linux,
  - The kernel keeps track only of the uid, which - as you noted - can
    be associated with several user names,
  - The database which associates ttys with login *names* is utmp, which
    on musl libc does not exist (see this definition in <utmp.h>:
    #define _PATH_UTMP "/dev/null/utmp"  ).
  - Even on systems which have /var/run/utmp, often the pseudo-ttys
    (allocated by terminal emulators) have no entry in /var/run/utmp;
    thus finding the "seat" of the screen on which a terminal emulator
    is running is hard.

Thus, on Linux systems, a correct implementation of getlogin() can not
distinguish different users with the same uid (with reasonable effort).
This applies to both glibc and the new code in gnulib.

Bruno

[1] https://pubs.opengroup.org/onlinepubs/9799919799/functions/getlogin.html







Information forwarded to bug-coreutils <at> gnu.org:
bug#76876; Package coreutils. (Sun, 09 Mar 2025 18:50:02 GMT) Full text and rfc822 format available.

Information forwarded to bug-coreutils <at> gnu.org:
bug#76876; Package coreutils. (Mon, 10 Mar 2025 03:11:02 GMT) Full text and rfc822 format available.

Message #37 received at 76876 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Bernhard Voelker <mail <at> bernhard-voelker.de>, 76876 <at> debbugs.gnu.org,
 P <at> draigBrady.com, nicolas.boos <at> wanadoo.fr
Subject: Re: bug#76876: logname output is often wrong when linked with glibc
Date: Sun, 9 Mar 2025 20:10:06 -0700
On 2025-03-09 09:04, Bernhard Voelker wrote:
> That gnulib commit will only be available with the next
> gnulib update in coreutils, obviously.

Yes, and just now I installed that update.




Information forwarded to bug-coreutils <at> gnu.org:
bug#76876; Package coreutils. (Mon, 10 Mar 2025 03:14:01 GMT) Full text and rfc822 format available.

Message #40 received at 76876 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Bruno Haible <bruno <at> clisp.org>
Cc: Nicolas Boos <nicolas.boos <at> wanadoo.fr>, Rich Felker <dalias <at> libc.org>,
 bug-gnulib <at> gnu.org, 76876 <at> debbugs.gnu.org
Subject: Re: bug#76876: logname output is often wrong when linked with glibc
Date: Sun, 9 Mar 2025 20:13:42 -0700
On 2025-03-09 11:49, Bruno Haible wrote:
> Nicolas Boos wrote:
>> This page says that the result of the logname command and the LOGNAME
>> variable must be the same:
>> https://www.ibm.com/docs/en/aix/7.3?topic=l-logname-command
> An AIX man page is not a specification for what we run on GNU systems.

Plus, that AIX man page is wrong even for AIX. Here's a /bin/sh 
transcript on AIX:

  $ export LOGNAME=ouch
  $ env | grep LOGNAME
  LOGNAME=ouch
  $ logname
  eggert
  $ uname -a
  AIX gcc119 3 7 00F9C1964C00

I.e., AIX agrees with GNU and conforms to POSIX.





Information forwarded to bug-coreutils <at> gnu.org:
bug#76876; Package coreutils. (Mon, 10 Mar 2025 05:25:02 GMT) Full text and rfc822 format available.

Message #43 received at 76876 <at> debbugs.gnu.org (full text, mbox):

From: Bruno Haible <bruno <at> clisp.org>
To: bug-coreutils <at> gnu.org, Nicolas Boos <nicolas.boos <at> wanadoo.fr>
Cc: Paul Eggert <eggert <at> cs.ucla.edu>, bug-gnulib <at> gnu.org, 76876 <at> debbugs.gnu.org,
 Rich Felker <dalias <at> libc.org>
Subject: Re: bug#76876: logname output is often wrong when linked with glibc
Date: Mon, 10 Mar 2025 06:24:45 +0100
I wrote:
> Thus, on Linux systems, a correct implementation of getlogin() can not
> distinguish different users with the same uid (with reasonable effort).
> This applies to both glibc and the new code in gnulib.

Let me document this limitation.


2025-03-10  Bruno Haible  <bruno <at> clisp.org>

	getlogin, getlogin_r: Document limitation.
	Reported by Nicolas Boos <nicolas.boos <at> wanadoo.fr> in
	<https://lists.gnu.org/archive/html/bug-gnulib/2025-03/msg00033.html>.
	* doc/posix-functions/getlogin.texi: Mention the "different user names
	with same uid" limitation.
	* doc/posix-functions/getlogin_r.texi: Likewise.

diff --git a/doc/posix-functions/getlogin.texi b/doc/posix-functions/getlogin.texi
index 0ccce336ce..b0b8da73ae 100644
--- a/doc/posix-functions/getlogin.texi
+++ b/doc/posix-functions/getlogin.texi
@@ -16,7 +16,8 @@
 This function is not declared unless @code{_POSIX} is defined on some platforms:
 mingw.
 @item
-This function returns the value of the @env{LOGNAME} environment variable:
+This function returns the value of the @env{LOGNAME} environment variable
+and this therefore arbitrarily fakeable:
 musl libc 1.2.5.
 @end itemize
 
@@ -26,4 +27,9 @@
 This function returns an empty string even when standard input is a tty
 on some platforms:
 HP-UX 11.11.
+@item
+When there are several user names with the same user ID,
+this function may return, instead of the user name that logged in,
+another user name that has the same user ID, on some platforms:
+Linux and others.
 @end itemize
diff --git a/doc/posix-functions/getlogin_r.texi b/doc/posix-functions/getlogin_r.texi
index df145ecfe2..0e3b7968db 100644
--- a/doc/posix-functions/getlogin_r.texi
+++ b/doc/posix-functions/getlogin_r.texi
@@ -21,7 +21,8 @@
 @code{ERANGE}, when the buffer is not large enough, on some platforms:
 macOS 14.
 @item
-This function returns the value of the @env{LOGNAME} environment variable:
+This function returns the value of the @env{LOGNAME} environment variable
+and this therefore arbitrarily fakeable:
 musl libc 1.2.5.
 @end itemize
 
@@ -42,4 +43,9 @@
 some platforms:
 @c https://dev.haiku-os.org/ticket/18349
 Haiku.
+@item
+When there are several user names with the same user ID,
+this function may return, instead of the user name that logged in,
+another user name that has the same user ID, on some platforms:
+Linux and others.
 @end itemize







Information forwarded to bug-coreutils <at> gnu.org:
bug#76876; Package coreutils. (Mon, 10 Mar 2025 05:26:02 GMT) Full text and rfc822 format available.

Information forwarded to bug-coreutils <at> gnu.org:
bug#76876; Package coreutils. (Mon, 10 Mar 2025 06:45:02 GMT) Full text and rfc822 format available.

Message #49 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Nicolas Boos <nicolas.boos <at> wanadoo.fr>
To: bug-coreutils <at> gnu.org
Cc: Bruno Haible <bruno <at> clisp.org>
Subject: bug#76876: logname output is often wrong when linked with glibc
Date: Mon, 10 Mar 2025 07:42:50 +0100
Bruno, thank you for all these clarifications.


Regarding cases such as "su --login" and users who share the same uid,
it might be interesting to add a few lines to the logname documentation.

It's still very confusing to have $LOGNAME with one value and the output
of logname with another.

NB

> Nicolas Boos wrote:
> > This page says that the result of the logname command and the LOGNAME
> > variable must be the same:
> > https://www.ibm.com/docs/en/aix/7.3?topic=l-logname-command
> 
> An AIX man page is not a specification for what we run on GNU systems.
> 
> > Thus, getlogin() implementations that use the LOGNAME or login_name
> > variables such as musl, uclibc or even gnulib WIN32 seems fine.
> 
> getlogin() is used for security and auditing purposes, for example,
> for recording who has made important system changes as 'root'.
> 
> The problem with getenv("LOGNAME") is that it is arbitrarily fakeable.
> For some uses, this may be fine. For other uses, it is not. And it's
> for the latter that POSIX specified the getlogin() function that
> accesses system-internal data structures that are not fakeable.
> (If every use-case was happy with getenv("LOGNAME"), there would be
> no need for a getlogin() function in POSIX.)
> 
> > Anyway, using a UID to get a login name like glibc's getlogin() function
> > does, we sometimes get incorrect results.
> > 
> > Here is a third test case, allowed by posix:
> > $ cat /etc/passwd
> > nicolas:x:1000:2001::/home/nicolas:/bin/bash
> > claude:x:1000:2002::/home/claude:/bin/zsh
> > 
> > localhost login: claude
> > Password:
> > $ echo $LOGNAME
> > claude
> > $ logname (glibc)
> > nicolas
> > $ logname (musl)
> > claude
> > $ logname (uclibc)
> > claude
> 
> Yes, POSIX [1] says "If getlogin() returns a non-null pointer, then that
> pointer points to the name that the user logged in under, even if there
> are several login names with the same user ID." This can be implemented
> on systems like FreeBSD, where the kernel keeps track of the user name
> as a string. But on Linux,
>   - The kernel keeps track only of the uid, which - as you noted - can
>     be associated with several user names,
>   - The database which associates ttys with login *names* is utmp, which
>     on musl libc does not exist (see this definition in <utmp.h>:
>     #define _PATH_UTMP "/dev/null/utmp"  ).
>   - Even on systems which have /var/run/utmp, often the pseudo-ttys
>     (allocated by terminal emulators) have no entry in /var/run/utmp;
>     thus finding the "seat" of the screen on which a terminal emulator
>     is running is hard.
> 
> Thus, on Linux systems, a correct implementation of getlogin() can not
> distinguish different users with the same uid (with reasonable effort).
> This applies to both glibc and the new code in gnulib.
> 
> Bruno
> 
> [1] https://pubs.opengroup.org/onlinepubs/9799919799/functions/getlogin.html
> 
> 
> 
> 
> 
> 




Information forwarded to bug-coreutils <at> gnu.org:
bug#76876; Package coreutils. (Wed, 19 Mar 2025 14:12:01 GMT) Full text and rfc822 format available.

Message #52 received at 76876 <at> debbugs.gnu.org (full text, mbox):

From: Eric Blake <eblake <at> redhat.com>
To: Bruno Haible <bruno <at> clisp.org>
Cc: nicolas.boos <at> wanadoo.fr, eggert <at> cs.ucla.edu, bug-gnulib <at> gnu.org,
 76876 <at> debbugs.gnu.org, dalias <at> libc.org
Subject: Re: bug#76876: logname output is often wrong when linked with glibc
Date: Wed, 19 Mar 2025 09:11:24 -0500
On Mon, Mar 10, 2025 at 06:24:45AM +0100, Bruno Haible via GNU coreutils Bug Reports wrote:
> I wrote:
> > Thus, on Linux systems, a correct implementation of getlogin() can not
> > distinguish different users with the same uid (with reasonable effort).
> > This applies to both glibc and the new code in gnulib.
> 
> Let me document this limitation.
> 

> -This function returns the value of the @env{LOGNAME} environment variable:
> +This function returns the value of the @env{LOGNAME} environment variable
> +and this therefore arbitrarily fakeable:

s/this/thus/ ?

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.
Virtualization:  qemu.org | libguestfs.org





Information forwarded to bug-coreutils <at> gnu.org:
bug#76876; Package coreutils. (Wed, 19 Mar 2025 14:37:05 GMT) Full text and rfc822 format available.

Message #55 received at 76876 <at> debbugs.gnu.org (full text, mbox):

From: Bruno Haible <bruno <at> clisp.org>
To: Eric Blake <eblake <at> redhat.com>
Cc: nicolas.boos <at> wanadoo.fr, eggert <at> cs.ucla.edu, bug-gnulib <at> gnu.org,
 76876 <at> debbugs.gnu.org, dalias <at> libc.org
Subject: Re: bug#76876: logname output is often wrong when linked with glibc
Date: Wed, 19 Mar 2025 15:35:58 +0100
Eric Blake wrote:
> > Let me document this limitation.
> > 
> 
> > -This function returns the value of the @env{LOGNAME} environment variable:
> > +This function returns the value of the @env{LOGNAME} environment variable
> > +and this therefore arbitrarily fakeable:
> 
> s/this/thus/ ?

Oops, thanks for reporting this. Fixed:


2025-03-19  Bruno Haible  <bruno <at> clisp.org>

	getlogin, getlogin_r: Fix typo in documentation.
	Reported by Eric Blake in
	<https://lists.gnu.org/archive/html/bug-gnulib/2025-03/msg00071.html>.
	* doc/posix-functions/getlogin.texi: Fix typo.
	* doc/posix-functions/getlogin_r.texi: Likewise.

diff --git a/doc/posix-functions/getlogin.texi b/doc/posix-functions/getlogin.texi
index b0b8da73ae..45cac08d89 100644
--- a/doc/posix-functions/getlogin.texi
+++ b/doc/posix-functions/getlogin.texi
@@ -17,7 +17,7 @@
 mingw.
 @item
 This function returns the value of the @env{LOGNAME} environment variable
-and this therefore arbitrarily fakeable:
+and is therefore arbitrarily fakeable:
 musl libc 1.2.5.
 @end itemize
 
diff --git a/doc/posix-functions/getlogin_r.texi b/doc/posix-functions/getlogin_r.texi
index 0e3b7968db..b4829559be 100644
--- a/doc/posix-functions/getlogin_r.texi
+++ b/doc/posix-functions/getlogin_r.texi
@@ -22,7 +22,7 @@
 macOS 14.
 @item
 This function returns the value of the @env{LOGNAME} environment variable
-and this therefore arbitrarily fakeable:
+and is therefore arbitrarily fakeable:
 musl libc 1.2.5.
 @end itemize
 







bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Thu, 17 Apr 2025 11:24:13 GMT) Full text and rfc822 format available.

This bug report was last modified 65 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.