[uClibc]getpass() prints password after hitting enter

Erik Andersen andersen at codepoet.org
Fri Apr 5 23:56:57 UTC 2002


On Thu Apr 04, 2002 at 12:12:44PM +0200, Axel Barnitzke wrote:
> Hi Eric,
> 
> the following patch solves the problem for me:
> 
> --- getpass.c   11 Jan 2001 11:42:17 -0000      1.2
> +++ getpass.c   4 Apr 2002 10:16:46 -0000
> @@ -45,7 +45,7 @@ getpass (prompt)
>    /* Try to write to and read from the terminal if we can.
>       If we can't open the terminal, use stderr and stdin.  */
> 
> -  in = fopen ("/dev/tty", "w+");
> +  in = fopen ("/dev/tty", "r+");
>    if (in == NULL)
>      {
>        in = stdin;
> @@ -61,7 +61,7 @@ getpass (prompt)
>        /* Save the old one. */
>        s = t;
>        /* Tricky, tricky. */
> -      t.c_lflag &= ~(ECHO|ISIG);
> +      t.c_lflag &= ~(ECHO|ICANON|ISIG);
>        tty_changed = (tcsetattr (fileno (in), TCSAFLUSH|TCSASOFT, &t) 
> == 0);
>      }

Applied -- for now.  This seems to be caused by differences in
how getc() works in uClibc vs glibc.  Perhaps when Manuel gets
back he can comment on why (without this patch) with uClibc we
see: 

uClibc strace:
    _llseek(3, 0, 0xbffff61c, SEEK_CUR)     = -1 ESPIPE (Illegal seek)
    write(3, "Please enter a password:", 24Please enter a password:) = 24
    read(3, "foo\n", 256)                   = 4
    _llseek(3, 0, 0xbffff620, SEEK_CUR)     = -1 ESPIPE (Illegal seek)
    write(3, "foo\n\n", 5foo

    )                  = 5
    ioctl(3, SNDCTL_TMR_CONTINUE, {B38400 opost isig icanon echo ...}) = 0
    close(3)                                = 0


but with glibc we see:
    write(3, "Please enter a password:", 24Please enter a password:) = 24
    read(3, "foo\n", 4096)                  = 4
    write(3, "\n", 1
    )                       = 1
    ioctl(3, SNDCTL_TMR_CONTINUE, {B38400 opost isig icanon echo ...}) = 0
    close(3)                                = 0

in particular, the write(3, "foo\n\n", 5) call in uClibc vs the 
write(3, "\n", 1) call in glibc.  Setting ICANON makes things work
for now, but is clearly not Right Thing(tm) as a long term solution.

 -Erik

--
Erik B. Andersen             http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--



More information about the uClibc mailing list