On Tue, Mar 20, 2012 at 8:51 PM, Gerd Stolpmann <info@gerd-stolpmann.de> wrote:

I second this. There is one OS where getlogin does not follow POSIX and is
maybe insecure, and the fix cannot be to hide the function for all other
OS. IMHO, these differences should be handled on a higher level, and not
in the module providing the bindings.

Semantically, there is a big difference between getlogin and getuid:
getlogin shall also work when the user calls a setuid program which in
turn invokes a script. These script commands can then use getlogin to
identify the original user (which is defined as the user of the session =
the user of the controlling terminal). In contrast, getuid would return
the uid to which setuid switched (for the script).

So, I'd say, you cannot repair getlogin with getuid. The best fix is
probably to just run `/usr/bin/logname </dev/tty` and read the printed
name.

I can think of a few solutions here:

We can use getuid only on platforms where getlogin is busted
We can name our function something other than "getlogin", to avoid confusion.
We can shell-out, in the way you suggest, to implement getlogin on Linux. My only worry is that this is also going to be somewhat fragile in its own way. Does calling out to logname with the suggested redirect always work?

I'm open to other suggestions.