I'm going to drop caml-list for further discussion of this issue.  People
who are interested should feel free to follow along on ocaml-core:

   https://groups.google.com/forum/?fromgroups#!forum/ocaml-core

y

On Tue, Mar 20, 2012 at 10:10 PM, Yaron Minsky <yminsky@janestreet.com>wrote:

> Looping in ocaml-core list.
>
> 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.
>
> y
>