From: oliver <oliver@first.in-berlin.de>
To: Till Varoquaux <till@pps.jussieu.fr>
Cc: yminsky@gmail.com, "David House" <dhouse@janestreet.com>,
"Ricardo Catalinas Jiménez" <jimenezrick@gmail.com>,
caml-list@inria.fr
Subject: Re: [Caml-list] Re: Unix.getlogin () fails when stdin is redirected
Date: Tue, 20 Mar 2012 23:45:25 +0100 [thread overview]
Message-ID: <20120320224525.GE3352@siouxsie> (raw)
In-Reply-To: <CAHJESt0O3yLjNPkexha_37OZQoLFobX4S-R1CZhvfzOasXWXgA@mail.gmail.com>
Are there so many bugs in glibc that fixing this one means waiting
in a long, long queue... and bugfixes will need months or years?
Are there any reasons this bug is not already fixed?
And since when is it known?
Ciao,
Oliver
On Tue, Mar 20, 2012 at 04:12:36PM -0400, Till Varoquaux wrote:
> As far as I can tell getpwuid(geteuid()) is what the (deprecated)
> cuserid function does. The linux man page explains the difference
> between the two functions like this:
>
> _ These functions let your program identify positively the user who
> is running (cuserid()) or the user who logged in this session
> (getlogin()). (These can differ when set-user-ID programs are
> involved.)
>
> I expect there to be more points were the behaviours of those two
> functions diverge (e.g.: sudo, deamons etc...).
>
> In general I am very skeptic any time I see a one liner that is sold
> as a working alternative to a glibc function. The glibc has issues and
> pitfalls but they tend to be very well documented. "Better the devil
> you know"...
>
> Till
>
> On Tue, Mar 20, 2012 at 3:41 PM, Yaron Minsky <yminsky@gmail.com> wrote:
> > Is there a concrete difference in behavior you're concerned about?
> >
> > y
> >
> >
> > On Tue, Mar 20, 2012 at 2:48 PM, Till Varoquaux <till@pps.jussieu.fr> wrote:
> >>
> >> getpwuid(getuid()) is not a synonym for get_login (refer to the
> >> discussion in the POSIX standard[^1]). You should not shadow posix
> >> functions by functions with different semantics in the Unix modules;
> >> providing your own abstraction over the OS is a commendable goal but
> >> you should do so without silently bypassing core functions.
> >>
> >> Till
> >> [1]:http://pubs.opengroup.org/onlinepubs/007904975/functions/getlogin.html
> >>
> >>
> >> On Tue, Mar 20, 2012 at 2:28 PM, David House <dhouse@janestreet.com>
> >> wrote:
> >> > Note that Jane Street's core library [1] does not use getlogin(3) in its
> >> > replacement Unix module, for exactly this reason:
> >> >
> >> > (* The standard getlogin function goes through utmp which is unreliable,
> >> > see the BUGS section of getlogin(3) *)
> >> > let getlogin_orig = Unix.getlogin
> >> > let getlogin () = (Unix.getpwuid (getuid ())).Unix.pw_name
> >> >
> >> > [1]: https://bitbucket.org/yminsky/ocaml-core/wiki/Home
> >> >
> >> > I just tested your specific example, and it worked fine.
> >> >
> >> >
> >> > On Tue 20 Mar 2012 06:07:59 PM GMT, Ricardo Catalinas Jiménez wrote:
> >> >>
> >> >> On Tue, Mar 20, 2012 at 06:51:13PM +0100, Ricardo Catalinas Jiménez
> >> >> wrote:
> >> >>>
> >> >>> I found out the next issue in this simple code:
> >> >>>
> >> >>> let () =
> >> >>> print_endline "Hello";
> >> >>> print_endline (Unix.getlogin ())
> >> >>>
> >> >>> Running in the normal case, with `./a.out' gives:
> >> >>>
> >> >>> Hello
> >> >>> ricardo
> >> >>>
> >> >>> But running like `./a.out</dev/null' makes Unix.getlogin fail:
> >> >>>
> >> >>> Hello
> >> >>> Fatal error: exception Unix.Unix_error(20, "getlogin", "")
> >> >>>
> >> >>> A simple strace reveals the problem:
> >> >>>
> >> >>> open("/etc/passwd", O_RDONLY|O_CLOEXEC) = 3
> >> >>> fstat(3, {st_mode=S_IFREG|0644, st_size=509, ...}) = 0
> >> >>> mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,
> >> >>> -1,
> >> >>> 0) = 0x7fb125554000
> >> >>> read(3, "root:x:0:0:root:/root:/bin/bash\n"..., 4096) = 509
> >> >>> read(3, "", 4096) = 0
> >> >>> close(3) = 0
> >> >>> munmap(0x7fb125554000, 4096) = 0
> >> >>> -> ioctl(0, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or
> >> >>> TCGETS, 0x7fff12682c98) = -1 ENOTTY (Inappropriate ioctl for device)
> >> >>> write(2, "Fatal error: exception Unix.Unix"..., 59) = 59
> >> >>> exit_group(2) = ?
> >> >>
> >> >>
> >> >>
> >> >> Someone knew the answer, man 3 getlogin reads:
> >> >>
> >> >> Note that glibc does not follow the POSIX specification and uses
> >> >> stdin instead of /dev/tty. A bug. (Other recent systems, like
> >> >> SunOS 5.8 and HP-UX 11.11 and FreeBSD 4.8 all return the login
> >> >> name also when stdin is redirected.)
> >> >>
> >> >>
> >> >> Regards
> >> >
> >> >
> >> >
> >> >
> >> > --
> >> > 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
> >> >
> >>
> >>
> >> --
> >> 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
> >>
> >
>
>
> --
> 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
>
next prev parent reply other threads:[~2012-03-20 22:45 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-20 17:51 [Caml-list] " Ricardo Catalinas Jiménez
2012-03-20 18:07 ` [Caml-list] " Ricardo Catalinas Jiménez
2012-03-20 18:28 ` David House
2012-03-20 18:48 ` Till Varoquaux
2012-03-20 19:41 ` Yaron Minsky
2012-03-20 20:12 ` Till Varoquaux
2012-03-20 22:45 ` oliver [this message]
2012-03-21 12:26 ` Török Edwin
2012-03-21 2:17 ` [Caml-list] " malc
2012-03-21 11:29 ` Gerd Stolpmann
2012-03-21 17:59 ` malc
2012-03-21 0:51 [Caml-list] " Gerd Stolpmann
2012-03-21 2:10 ` Yaron Minsky
2012-03-21 2:22 ` Yaron Minsky
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120320224525.GE3352@siouxsie \
--to=oliver@first.in-berlin.de \
--cc=caml-list@inria.fr \
--cc=dhouse@janestreet.com \
--cc=jimenezrick@gmail.com \
--cc=till@pps.jussieu.fr \
--cc=yminsky@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox