Reading Passwords From /dev/tty

[Daniel Kahn Gillmor]

Hi Evan--

On Tue 2017-08-01 05:26:03 +0000, Evan Klitzke wrote:
> I have seen some other projects that read passwords by putting stdin into
> no echo mode, and then literally just reading from stdin. This *does* seem
> to work (assuming you make sure to restore echoing after reading the
> password!), but I am curious why projects like GPG and sudo prefer using
> /dev/tty. Does anyone know what the argument is for using a pseudo-TTY?

gpg might be used in a pipeline from within a terminal.  In that case,
the program might want to know the "controlling terminal" for the
process (see the manpage tty(4) e.g. via "man 4 tty"), and it might
choose to prompt the user there, even if stdin, stdout, and stderr are
all pointing somewhere else.

does that make sense?  Consider the following program:



/* controlling-terminal.c */
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <stdio.h>
#include <errno.h>
#include <string.h>
#include <unistd.h>

int main(int argc, const char * argv[]) {
  int fd = open("/dev/tty", O_RDWR);
  if (fd != -1) {
    fprintf(stderr, "opened as fd %d\n", fd);
    write(fd, "abc123\n", 7);
  } else {
    fprintf(stderr, "did not open: (%d) %s", errno, strerror(errno));
  }
  return 0;
}
/* end controlling-terminal.c */




If you compile and then run it in a shell pipeline like this:

   echo test | ./controlling-terminal 2>/dev/null | cat > /dev/null

the result is that -- even though the process has no file descriptor
open that is associated with the tty -- it still manages to print
"abc123\n" to the tty.  That's useful output for a password prompt.  And
input (e.g. for reading a password from the user) works the same way.

hth,

        --dkg


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: </pipermail/attachments/20170801/766c6d6f/attachment.sig>