On 18/04/2026 09:14, Bruno Haible via Gnulib discussion list wrote:
Consider these two implementations of getlogin() on Linux: - the glibc one (used on systems with glibc), - the gnulib one (used on systems with musl libc).There are two implementation differences: 1) The gnulib one, when configured with --enable-systemd, uses libsystemd instead of utmp/utmpx. 2) The gnulib one has a fallback that uses the owner of the tty connected to stdin. My question is: Is 2) a good thing or not? One of the cases where it matters is when the 'logname' command is used within an 'unshare -U' command. In this case, the glibc implementation returns a failure, whereas the gnulib implementation returns "nobody". This is because the tty's owner is different from the perspective of a call within an 'unshare -U' command: $ ls -l /proc/self/fd/0 lrwx------ 1 bruno bruno 64 18. Apr 10:00 /proc/self/fd/0 -> /dev/pts/28 $ ls -li /dev/pts/28 31 crw------- 1 bruno tty 136, 28 18. Apr 10:01 /dev/pts/28 $ unshare -U ls -li /dev/pts/28 31 crw------- 1 nobody nogroup 136, 28 18. Apr 10:01 /dev/pts/28 Which is better in this circumstance? A 'logname' program that prints 'logname: no login name'? Or a 'logname' program that prints "nobody"? If the conclusion is that failure is better, we should remove the fallback 2) from Gnulib. If the conclusion is that returning "nobody" is better, we should override getlogin() on glibc systems and keep the fallback 2). Bruno
I'm not sure. I'm leaning towards showing an error for this case, as getlogin() returns "user logged in on the controlling terminal of the process", and if there is no corresponding user name in the new user namespace then it seems wrong to map to "nobody". In general we should align with newest glibc anyway unless it's clearly broken. cheers, Padraig
