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, than
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 c
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
getlogin, getl
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
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
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.
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
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
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 t
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
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:
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-
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
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
14 matches
Mail list logo
