"sudo logname" should return my username instead of "root"

[stormbeforesunsetbee]

System

• xuname:

  • Void 5.12.19_1 x86_64-musl GenuineIntel uptodate rrFFFF

• package:

  • coreutils-8.32_4

Expected behavior

Returns my username just like any other distro

Actual behavior

Returns "root"

Steps to reproduce the behavior

Run sudo logname

[ericonr]

logname uses libc getlogin(), which on musl just returns the value of LOGNAME, which sudo and doas set to root. Since uid is 0, I'd say a LOGNAME of root is correct, and reporting that doesn't seem so erroneous.

[stormbeforesunsetbee]

Actually, I just worry if this will affect other programs behavior

[ericonr]

The man page is pretty clear about not relying on getlogin for security, and I did a quick local audit of what I have installed and didn't find any egregious usage. So the only issue would be wrong username in some error messages or syslogs. Not terrible, still kinda meh, but fixing all that would be a lot of work, I think.

[loreb]

POSIX says that "The login name shall be the string that would be returned by the getlogin() function", so that's it.

One could argue that musl implements getlogin incorrectly - "a string containing the user name associated by the login activity with the controlling terminal of the current process" looks to me like they don't care if you ran sudo or equivalent, but rather only what you logged in as; I hope to be wrong here, because if I'm running anything as root I'd expect getlogin & friends to say I'm root.

That being said, I'm not a POSIX lawyer, so...

• linux: unclear
• openbsd: "This is true even if some of those processes assume another user ID, for example when su(1) is used"
• freebsd/netbsd: same as openbsd
• illumos (https://illumos.org/man/3c/getlogin) uses utmpx, similar to IBM
  ... so overall I suppose this is a bug in musl's implementation of getlogin,
  but as they intentionally don't implement the utmp functions I'm not sure how to fix that.

[ericonr]

@loreb arguably it's more on sudo and doas that set LOGNAME at all, since the env var is only supposed to be set at login, and should be inherited by applications. I'm okay with them doing it, but that messes with musl's assumption here.

[loreb]

@ericonr til that LOGNAME is actually specified by POSIX, I didn't know that... still doas says it sets LOGNAME, period, and sudo says it does unless special precautions are taken.

If I understand correctly:

• musl is technically correct relying on LOGNAME,
• sudo & doas setting LOGNAME is technically incorrect (but probably the right choice) unless they actually login with utmp etc (doas doesn't, sudo mentions utmp/wtmp enough time that I believe they do)

so either musl resorts to strange hacks to handle the situation or until the musl guys do something like https://skarnet.org/software/utmps/ (unlikely) it looks to me like the current behavior is the least-worst option.

[stormbeforesunsetbee]

Thank you guys for replying!

@loreb Is utmps a logname alternative? How can I use that. I couldn't find the package

[rivanfebrian123@RVN ~]$ xlocate utmps
runit-2.1.2_11	/usr/bin/utmpset
runit-2.1.2_11	/usr/share/man/man8/utmpset.8

@ericonr
Let's say musl doesn't really wanna meet POSIX standard because of their principle, but at least, it should be as close as possible to POSIX. Maybe they can return these fallbacks:

1. $SUDO_USER
2. $LOGNAME
3. $USER

In sudo, $LOGNAME simply returns "root", not my username, so use $SUDO_USER instead

@ALL
Could you guys try those fallbacks on doas? I gotta finish my homework assignment in an hour

[ericonr]

doas sets DOAS_USER. And USER is set to root anyway.

But the possibility of musl complicating the implementation of a trash function by hardcoding knowledge of the currently most used capability raising programs is really quite low.

[fosslinux]

I don't see any reason for the current behaviour in musl to change based on the POSIX standard outlined earlier. If anything should change, this should be raised with sudo and doas, but IMO I don't see much of an issue with that anyway.

I haven't ever seen evidence of a bad LOGNAME in musl affecting anything on my systems.

[loreb]

@rivanfebrian123 sorry for the late reply!
Anyway no, it's not a program, it's a set of functions that are supposed to maintain a database of logged in users; the musl developers decided that the specification is so ill designed that it's basically impossible to implement correctly, so they decided to leave those functions as stubs (briefly described at https://wiki.musl-libc.org/faq.html and https://skarnet.org/software/utmps/ - "in particular, it is impossible...").

TLDR: properly implementing logname requires something called getlogin; properly implementing getlogin requires the utmpx functions (see https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/getlogin.c;hb=HEAD), and the musl developers think the utmpx functions were designed by monkeys and it's better not to have them.

https://skarnet.org/software/utmps/ is trying a different approach - to have a daemon deal with the utmp file and rewrite all the utmp functions to make them talk to the daemon, which should work, but

1. the program is still beta, and
2. it requires that a daemon is running, and
3. the client part is written using a library (libska) which is not part of the standard C library

Sorry for the mouthful and sorry again for being so late.

[stormbeforesunsetbee]

Actually, I'm okay with that as the current POSIX spec doesn't require returning output of getlogin, as far as I know. But again, I'm just worrying about shell programmers who didn't know about this. Maybe their shell programs don't run as they intended or something like that. But yeah, software testing is definitely their responsibility :)

[ericonr]

Anyone using logname for verifying identity in a script is doing something very wrong.

[stormbeforesunsetbee]

Maybe you right. But we can't solely blame them tho: https://www.ibm.com/docs/en/zos/2.2.0?topic=descriptions-logname-return-users-login-name. Well, I think it's okay to close this issue now

[ericonr]

That page makes it clear it uses env vars and can't really be trusted. Should be fine.

I will close this, then.

I forgot to mention, I pushed 56a567d after my investigation into this issue. It's probably minor, but just a note.

[ericonr]

Thanks for bringing this up, anyway!