GNU bug report logs -
#76876
logname output is often wrong when linked with glibc
Previous Next
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.
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):
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):
[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):
[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):
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):
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):
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):
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):
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):
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):
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):
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):
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):
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):
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.