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 q2L2AOIj032596 for ; Wed, 21 Mar 2012 03:10:24 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvoBAG03aU8machwl2dsb2JhbAA6CrZoKgEBAQEBBhgHO4IJAQEBAwESAiwBATcBDwsEBwM4IhIBBQEcBhMIEweHYwUDmTIKileELQGOYAaKWIYplWKOSD2EJQ X-IronPort-AV: E=Sophos;i="4.73,621,1325458800"; d="scan'208";a="150450253" Received: from mx1.janestreet.com (HELO nyc-dmz-mxout1.janestreet.com) ([38.105.200.112]) by mail1-smtp-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 21 Mar 2012 03:10:21 +0100 Received: from nyc-qsv-mail1.delacy.com ([172.25.22.57]) by nyc-dmz-mxout1.janestreet.com with esmtp (Exim 4.76) (envelope-from ) id 1SAB0F-0004m7-Op for caml-list@inria.fr; Tue, 20 Mar 2012 22:10:19 -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 1SAB0F-0005F2-MZ for caml-list@inria.fr; Tue, 20 Mar 2012 22:10:19 -0400 Received: from mail-vb0-f42.google.com ([209.85.212.42]) by mxgoog1.janestreet.com with esmtp (Exim 4.76) (envelope-from ) id 1SAB0F-0002Yw-Kc for caml-list@inria.fr; Tue, 20 Mar 2012 22:10:19 -0400 Received: by vbjk13 with SMTP id k13so328982vbj.29 for ; Tue, 20 Mar 2012 19:10:19 -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=lN/qOdgX86XeoZrCqfyLS6/+lKBfnzoWv0jiy3Dy3Yw=; b=Oqky9+A+C5l7GnDR19PaAamxTtsimZRFNU2HRiIXOZoumMnwoSQcReEr/YRnH/DdUp Ijw9y0ouHs3kQ856mCiEbE+xmg73F6y6KYN9w4zls74RS65iIACDe1adsaFqttN84DDp JIQtanIy/OEscPxUa/rflTQnHr7niJ5JmZ9/A= 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=lN/qOdgX86XeoZrCqfyLS6/+lKBfnzoWv0jiy3Dy3Yw=; b=KWuzLuttEpLB2/TyKXwsLeKINlt7VLzad+Z7VNdLrwnEWhLqwFeSf3GCbF06yu69qg g8KoX88k+qFCllTm3+utFXhEaLNoJHg4jNvajgYtCIgCBAeHm3MaNq/8lED/fixP5cDQ Duc15Hukw4OdjwATJn175NwOBSqy0IW2RzgujiVQI3yc3W7POnNDRofxi4n/DdNRKsTK BMfidzyW8orPHWkJOS8cvzGQ7ZZGjmx+aZkVeS3tLWNGJ0fbAl2zhXBTldVqq22QUm5u ZHPgSr1EE1Rz4q4hykdnw35qIYYIohbFIg00we057lSdeD0NT6jrr+JvvYH/BWE6x5CY q+Jw== MIME-Version: 1.0 Received: by 10.52.68.164 with SMTP id x4mr942245vdt.16.1332295819242; Tue, 20 Mar 2012 19:10:19 -0700 (PDT) Received: by 10.52.172.69 with HTTP; Tue, 20 Mar 2012 19:10:18 -0700 (PDT) X-Originating-IP: [72.225.238.212] In-Reply-To: References: Date: Tue, 20 Mar 2012 22:10:18 -0400 Message-ID: From: Yaron Minsky To: Gerd Stolpmann Cc: caml-list@inria.fr, ocaml-core@googlegroups.com Content-Type: multipart/alternative; boundary=20cf307f30a20aadfa04bbb74b83 X-Gm-Message-State: ALoCoQk/P3oc7wthKtHpcfze8v6u7e0MU5x6I5v5bhCCS71h/N78NTgjZxJEAAgEpXg9QslPLyLP Subject: Re: [Caml-list] Re: Unix.getlogin () fails when stdin is redirected --20cf307f30a20aadfa04bbb74b83 Content-Type: text/plain; charset=ISO-8859-1 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 --20cf307f30a20aadfa04bbb74b83 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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<= 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 solutions he= re:
  • We can use getuid only on platforms where getlogin is= busted
  • We can name our function something other than "getlogi= n", 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
--20cf307f30a20aadfa04bbb74b83--