[Python-Dev] Possible bugs and security holes in getpass.py (original) (raw)

Jeff Epler jepler at unpythonic.net
Mon Dec 1 22:55:16 EST 2003

On Mon, Dec 01, 2003 at 06:53:18PM -0800, Oleg Zabluda wrote:

I am comparing getpass.py (http://cvs.osafoundation.org/index.cgi/osaf/chandler/python/Lib/getpass.py) and getpass.c from glibc (http://sources.redhat.com/cgi-bin/cvsweb.cgi/libc/misc/getpass.c?rev=1.18&content-type=text/x-cvsweb-markup&cvsroot=glibc).

Many of the differences you cite seem related to glibc-specific internals (I don't know what it means to 'lock "stdin"', open 'in "c" mode', or 'set _IO_FLAGS2_NOTCANCEL', when talking about portable stdio code, though I'm not a posix/SuS expert). glibc-specific code is unlikely to be included in Python, for obvious reasons.

4. getpass.c explicitly flushes "stdin" after outputting the promt and before reading the password.

In 2.2, I think the marked lines are supposed to perform those functions: try: termios.tcsetattr(fd, termios.TCSADRAIN, new) ### HERE passwd = _raw_input(prompt) finally: termios.tcsetattr(fd, termios.TCSADRAIN, old) ### HERE

Suggestion/RFC: either implement the same functionality or a portion thereof in getpass.py, or implement it using getpass(3) directly, at least when linking with glibc.

I think that a _getpass module on systems that provide getpass(3) would be appropriate. The block at the bottom of getpass.py would have another level added to deal with the import of _getpass and its absence:

try: import _getpass except: existing block, but indented more else: getpass = _getpass.getpass

There's probably nothing subtle about writing _getpassmodule.c, and distutils should be able to handle its absence gracefully (?).

Before I'm +1 on doing this, though, here's what the linux (redhat 9) manpage has to say about getpass: SYNOPSIS #include <unistd.h>

           char *getpass( const char * prompt );

    DESCRIPTION
           This function is obsolete. Do not use it.
                            ^^^^^^^^

The opengroup web page you mention says it is "LEGACY", with this explanation: This function was marked LEGACY since it provides no functionality which a user could not easily implement, and its name is misleading. ... how important is getpass, and did the opengroup really underestimate the subtlety of its implementation that greatly?

Jeff

More information about the Python-Dev mailing list