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'm not sure how bad I feel about having surprising results in that degenerate case!
Anil, do you have a view as to what Core should do for getlogin? I'm still not sure we should change anything, or if we should, what change to make...
I am sure that I hate Unix, though. That Xen client thing is sounding better every day...
let getlogin () = `You_probably_mean_get_my_user_name
let getlogin_really () = Unix.getlogin ()
let get_my_user_name () = (Unix.getpwuid (getuid ())).Unix.pw_name
(Plus, obviously, helpful comments in the mli.)
This approach is pretty successful inside async. You are saved from
introducing bugs due to deficiencies in libc, but if you really want
getlogin(3), you have it. If you want it a lot, you can always rebind
it locally.
On Wed 21 Mar 2012 12:37:11 PM GMT, Anil Madhavapeddy wrote:
> I agree with Till; the least surprising thing is to pass through the
> underlying {g}libc library call. Any higher-level replacement can just
> have a different name (for example, a version that goes through the
> password database and returns *all* logins associated with the {e}uid
> might be the safest thing).
>
> Xen thing making good progress. Soon! :-)
>
> -Anil
>
> On 21 Mar 2012, at 11:47, Yaron Minsky wrote:
>
>> I'm not sure how bad I feel about having surprising results in that
>> degenerate case!
>>
>> Anil, do you have a view as to what Core should do for getlogin? I'm
>> still not sure we should change anything, or if we should, what
>> change to make...
>>
>> I am sure that I hate Unix, though. That Xen client thing is sounding
>> better every day...
>>
>> On Mar 21, 2012 7:35 AM, "Anil Madhavapeddy" <an...@recoil.org
>>> * 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
I find the name getlogin unfortunate, as it sounds a lot more promising
than it really is. The best solution is probably more explicit names
and education.
(** A wrapper for the libc getlogin call. You should probably
use Sys.get_terminal_user instead.
Raises a Unix_error if something goes wrong.
*)
Unix.posix_getlogin : unit -> string
(** [get_terminal_user ()] attempts to determine the name of the user sitting
at the terminal. This relies on environment clues (such as Unix.posix_getlogin).
This function may fail for daemons and detached processes.
The name returned is not necessarily the user this process is executing as.
See get_effective_user for that.
*)
Sys.get_terminal_user : unit -> string option
(** [get_effective_user ()] looks up the name of the user this process can
access files as, send signals as, etc. The name corresponds to the UNIX
effective uid. It's not necessarily the name of the user sitting at
the terminal.
*)
Sys.get_effective_user : unit -> string
(*
Implementation:
let get_effective_user () = (Unix.getpwuid (Unix.geteuid ())).Unix.pw_name
*)
On Thu, Mar 22, 2012 at 04:15:26PM +0000, David House wrote:
> This looks nice, but I'd say that the comment for
> [Unix.posix_getlogin] should actually refer the user to
> [Sys.get_effective_user] -- right?
>
> On 22 March 2012 16:07, <mb...@panix.com> wrote:
> > House is on the right track.
> >
> > I find the name getlogin unfortunate, as it sounds a lot more promising
> > than it really is. ?The best solution is probably more explicit names
> > and education.
> >
> > (** A wrapper for the libc getlogin call. ?You should probably
> > ? ?use Sys.get_terminal_user instead.
> >
> > ? ?Raises a Unix_error if something goes wrong.
> > ?*)
> > Unix.posix_getlogin : unit -> string
> >
> > (** [get_terminal_user ()] attempts to determine the name of the user sitting
> > ? ?at the terminal. ?This relies on environment clues (such as Unix.posix_getlogin).
> >
> > ? ?This function may fail for daemons and detached processes.
> >
> > ? ?The name returned is not necessarily the user this process is executing as.
> > ? ?See get_effective_user for that.
> > ?*)
> > Sys.get_terminal_user ?: unit -> string option
> >
> > (** [get_effective_user ()] looks up the name of the user this process can
> > ? ?access files as, send signals as, etc. ?The name corresponds to the UNIX
> > ? ?effective uid. ?It's not necessarily the name of the user sitting at
> > ? ?the terminal.
> > ?*)
> > Sys.get_effective_user : unit -> string
> >
> > (*
> > ?Implementation:
> > ? ?let get_effective_user () = (Unix.getpwuid (Unix.geteuid ())).Unix.pw_name
> > *)