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 <ymin...@janestreet.com>wrote: > Looping in ocaml-core list. > > On Tue, Mar 20, 2012 at 8:51 PM, Gerd Stolpmann <i...@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 > -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
