On Sun, Feb 24, 2008 at 1:02 PM, Shaya Potter wrote:

[please cc me on responses]

I was wondering if getpass could be changed to enable piped stdin to work.

For instance, the getmail program can read my email password in via stdin using getpass functionality.

However, if I do

echo password | getmail4

it will fail due to stdin not being a terminal and therefore not being able to do a old = termios.tcgetattr(fd) on it.

From what I can tell, the point of this is to only to prevent echoing the password, which isn't a problem in the echo case I give (especially if using bash, then it wont even be on the cmdline when run from a script as it's a builtin, script can also read in the password and store it in memory).

currently the code is

----- def unix_getpass(prompt='Password: '): """Prompt for a password, with echo turned off.

Restore terminal settings at end. """

try: fd = sys.stdin.fileno() except: return default_getpass(prompt)

old = termios.tcgetattr(fd) # a copy to save new = old[:]

new[3] = new[3] & ~termios.ECHO # 3 == 'lflags' try: termios.tcsetattr(fd, termios.TCSADRAIN, new) passwd = _raw_input(prompt) finally: termios.tcsetattr(fd, termios.TCSADRAIN, old)

sys.stdout.write('\n') return passwd -----

it would seem that if the tcgetattr() line is moved into the initial try, my echo case would work as expected (as it would fail, but be caught and then just run default_getpass() (which should just read it from stdin).

Is there any reason not to do it this way?

It's certainly possible to have getpass() read from stdin automatically, but it's traditionally understood that having it read from a tty is much, much better. Suppose your program were meant to use getpass, and then read a file from stdin. Now, all of a sudden, you miss the first line of the file, and it becomes your password, for no particular reason. getpass() works the way it does because it's been working that way in C for decades. If you really want to maintain a 'configuration file' for your password, or have it available on command line, try adding an option like -p <PASSWD> or -p <PASSFILE> to whatever program you're writing. -- Cheers, Leif

On Tue, Feb 26, 2008 at 12:43 PM, Shaya Potter wrote:

the -p <PASSWD> option is not good on multi user systems the -p <PASSFILE> option is not particularly good on NFS based systems (have to trust every user on every machine with access to NFS share)

You seem somehow both worried about security, yet too lazy to type in your password. I think at some point, one of those concerns is going to have to give.

and now, assuming what you say is part of the design behind the code

what's the point of this part of the code

...

...

try: fd = sys.stdin.fileno() except: return default_getpass(prompt)

i.e. the exception handler, default_getpass() is always going to read from stdin at the end of the day.

line = sys.stdin.readline()

I'm assuming I'm missing something

Sorry, I only know my way around the libc version of getpass(), not the python one. In that version, typically we try to open /dev/tty for reading, and if that fails, we fall back to stdin. I presume that's what's going on here, but the first line appears to be getting stdin anyway, so I'm no longer sure. That said, why don't you just use default_getpass() in your code, if it reads from stdin to begin with? -- Cheers, Leif

On Tue, Feb 26, 2008 at 1:18 PM, Shaya Potter wrote:

I want to run a program within a bash script, essentially daemonize a program that doesn't have a daemon mode.

#!/bin/sh

echo "What Is Your Passsword: " stty_orig=`stty -g` stty -echo read -r PASSWORD stty $stty_orig

TIMEOUT=600

while [ 1 ] do echo $PASSWORD | program

So...why won't `program -p $PASSWORD' work here?

sleep $TIMEOUT done

-- Cheers, Leif

Charles Cazabon wrote:

Shaya Potter wrote:

...

Leif Walsh wrote:

...

On Tue, Feb 26, 2008 at 12:43 PM, Shaya Potter wrote:

...

the -p <PASSWD> option is not good on multi user systems the -p <PASSFILE> option is not particularly good on NFS based systems (have to trust every user on every machine with access to NFS share) You seem somehow both worried about security, yet too lazy to type in your password. I think at some point, one of those concerns is going to have to give.

That was exactly what I've been telling this user on the getmail mailing list for the last week. Apologies that he's decided to bother you with it.

actually, 1) I am willing to type in the password, which is obvious to anyone who can read a simple script. That just doesn't work for a program you want to run in the background to type it in every time. 2) I was trying to understand why python made it's design decision, I don't need you apologizing for me trying to understand that (and I do ave a better understanding now) For those who want the background to make up their own minds about why I asked. Charles is the author of a program called getmail that is used for fetching email. - generally to fetch email you need a password. getmail will either read a passowrd in via getpass() or read it from a file. however, storing the password in a file is out of the question in this case (NFS), but reading the password in is fine, I'm not concerned with a threat of it being read out of memory. However, getmail doesn't have a daemon mode, charles recommends using the password in a file + cron, which I'd be fine with if I could store the password in a file. However, as I can't, I wanted to daemonize it via a script (already posted), that reads in a password from stdin and passes it to getmail via its stdout and getmail's stdin. However, that doesn't work with getpass() which getmail uses, and Charles isn't willing to change his program (it's his program he's allowed to do with it what he wants). I cam here after examining the python code and being confused by it and wanting to understand the design decision that went into it, as I sort of do now as I said in my last real email on the subject "understand the eating stdin aspect" That's it. Personally, I debated sending this email (don't need to waste people's time), but I don't appreciate being called out in public as Charles did when in truth while my question was spurred on by getmail it was something I was generally interested in understanding as well.

Leif Walsh wrote:

On Tue, Feb 26, 2008 at 2:14 PM, Shaya Potter wrote:

...

1) I am willing to type in the password, which is obvious to anyone who can read a simple script. That just doesn't work for a program you want to run in the background to type it in every time.

I recommend you just hack on this getmail program and give it a daemon mode. That shouldn't be too large of a task, and it will certainly be more secure (and you can even commit your changes as a new feature!). Otherwise, your best bet is probably, as Charles said, making the passfile work for you (maybe play with nfs and see if you can get it to hide things...I'm no wizard with it, but I'm willing to bet it's possible).

I don't disagree (though nfs will never work, think root exploit on another machine, squash_root doesn't help). I wasn't posting here about how to change getmail (I can make those changes easily), the issue was simply understanding python's getpass(). Which you answered my question on, so thank you.