From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id q2L2MC06000726 for ; Wed, 21 Mar 2012 03:22:12 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvoBAB47aU8machzl2dsb2JhbAA4CrZxKgEBAQEBCBYHO4IJAQEBAwESAiwBATcBBAsLBAcDOCISAQUBHAYTGweHYwUDCKBqCopXhC0BhnsCBIpYhimVYo5IPYQl X-IronPort-AV: E=Sophos;i="4.73,621,1325458800"; d="scan'208";a="150450869" Received: from mx2.janestreet.com (HELO nyc-dmz-mxout2.janestreet.com) ([38.105.200.115]) by mail1-smtp-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 21 Mar 2012 03:22:06 +0100 Received: from nyc-qsv-mail1.delacy.com ([172.25.22.57]) by nyc-dmz-mxout2.janestreet.com with esmtp (Exim 4.76) (envelope-from ) id 1SABBZ-000693-Fv for caml-list@inria.fr; Tue, 20 Mar 2012 22:22:01 -0400 Received: from nyc-dmz-mxgoog1.delacy.com ([172.25.224.109] helo=mxgoog1.janestreet.com) by nyc-qsv-mail1.delacy.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) (envelope-from ) id 1SABBZ-0005wk-EL for caml-list@inria.fr; Tue, 20 Mar 2012 22:22:01 -0400 Received: from mail-vx0-f170.google.com ([209.85.220.170]) by mxgoog1.janestreet.com with esmtp (Exim 4.76) (envelope-from ) id 1SABBZ-0002zn-Bj for caml-list@inria.fr; Tue, 20 Mar 2012 22:22:01 -0400 Received: by vcbfo14 with SMTP id fo14so777045vcb.29 for ; Tue, 20 Mar 2012 19:22:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=janestreet.com; s=google; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=bFJvUT5Qg4ZANa78EXp0dnfMuxxYJa5D4C1tcLx9dos=; b=SVzfnuzd2fAf4fbjgKYk6+wyFHkUdmY5lC5cPAZOpki7GZjfoC81Rg/ti+ScRcWUFz cETaP7OYklL9MenATyqEIMDu8J4826P3764aC6Nywbk5U733Z9fZITacCC3qTXiExiHT HQBNXDvKtFxD4AxW508oYbS1YrNrSVi/aRBms= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=bFJvUT5Qg4ZANa78EXp0dnfMuxxYJa5D4C1tcLx9dos=; b=Sh1eRxqmJMFLih6PY565VDyq1wdePBck/xoUn9aR4EMld3o8EAAX+2XXoi5ERLDzWn QL5odX1trJ9q5xH2EX9fmEeT0b8t4gEps81Yy6bbiLh+RX8fN/jkWVm/RnhW0Gl4bADM tVcaJNOchPwdtjN+B+fmPKhe+IMSIQGPxV8Hg7FRLLQyJ4FtD8CIpQhG4N6yn7WR7J0D O/fw1VepiSOk+CdzM3GhCoHGTIrx1e3q0FiAaDUR6DeQawFyVZTEBF0AcHsWeRU4tv4C Dgngr5CqU6qKq0JP/DGS0LJylN5rfJyAoIKjkhy5bJkWFDJOHfL23UJHI/RCQ/37fKEV aOew== MIME-Version: 1.0 Received: by 10.52.70.84 with SMTP id k20mr890864vdu.67.1332296521076; Tue, 20 Mar 2012 19:22:01 -0700 (PDT) Received: by 10.52.172.69 with HTTP; Tue, 20 Mar 2012 19:22:01 -0700 (PDT) X-Originating-IP: [72.225.238.212] In-Reply-To: References: Date: Tue, 20 Mar 2012 22:22:01 -0400 Message-ID: From: Yaron Minsky To: Gerd Stolpmann Cc: caml-list@inria.fr, ocaml-core@googlegroups.com Content-Type: multipart/alternative; boundary=20cf307d0124dfcf4e04bbb77402 X-Gm-Message-State: ALoCoQniSmJgQ3J/XDKtbxbmGqzXL0akEmL1v5GTY/UG1AKc4qTLyOVGoiuoL2j44O6GO8T3EyLJ Subject: Re: [Caml-list] Re: Unix.getlogin () fails when stdin is redirected --20cf307d0124dfcf4e04bbb77402 Content-Type: text/plain; charset=ISO-8859-1 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 wrote: > Looping in ocaml-core list. > > On Tue, Mar 20, 2012 at 8:51 PM, Gerd Stolpmann 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 > 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 > --20cf307d0124dfcf4e04bbb77402 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I'm going to drop caml-list for further discussion of this issue. =A0Pe= ople who are interested should feel free to follow along on ocaml-core:

y

On Tue, Mar 20, 201= 2 at 10:10 PM, Yaron Minsky <yminsky@janestreet.com> wrote:
Looping in ocaml-core list.

On Tue, Ma= r 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<= br> 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 =3D=
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 soluti= ons here:
  • We can use getuid only on platforms where getlo= gin is busted
  • We can name our function something other than "g= etlogin", to avoid confusion.
  • We can shell-out, in the way you suggest, to implement getlogin on Linu= x. =A0My only worry is that this is also going to be somewhat fragile in it= s own way. =A0Does calling out to logname with the suggested redirect alway= s work? =A0
I'm open to other suggestions.

y

--20cf307d0124dfcf4e04bbb77402--