On Fri, 10 Jan 2003 12:30:46 -0500, "wkearney99"
<wkearney99@hotmail.com> wrote:

> Has any consideration been given to allowing the mailutil program
> to support stdin or command line password usage? It'd be nice if
> it would support this. Otherwise scripted use of mailutil ends up
> requiring use of expect. It sort of seems like a real waste.


On Fri, 10 Jan 2003 10:34:38 -0800, Mark Crispin
<mrc@CAC.Washington.EDU> wrote:

> Command line will not happen. Consider "ps" for the reason why.

> Stdin is a possibility, although it can be noted that expect works
> quite well for mailutil and other tools which require passwords.


Ahem.

mailutil calls the c library function "getpass" to get the user's
password. And the (uclibc) libc/unistd/getpass.c source code says:


> /* 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", "r+");
> if (in == NULL)
> {
> in = stdin;
> out = stderr;
> }
> else
> out = in;


So if we can find some way to run our script without a controlling
terminal, getpass() will grab the password from stdin, and we won't
need expect.

Hey! How about cron? Here's one that works for me:

> SHELL=/bin/bash
> PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin
>
> # m h dom mon dow command
> */20 * * * * mailutil appenddelete '{www.fastmail.fm:993/imap/norsh/notls/ssl/novalidate-cert/user="isp2dial@fastmail.fm"}INBOX' '{mail.isp2dial.com:143/imap/norsh/notls/user="jak"}INBOX' 2>&1 | grep -v '^password: password:'%mypass1%mypass2


The uw-imap docs/naming.txt file describes the {remote_system} /flags,
which are very handy to know! And as the crontab(5) man page says:

> Percent-signs (%) in the command, unless escaped with backslash (\),
> will be changed into newline characters, and all data after the first
> % will be sent to the command as standard input.


To wrap things up:

The getpass() "password:" prompts go to stderr, producing output which
can cause the cron job to send a mail every time it runs.

That's why I redirect stderr to the "grep -v" pipe, filtering out the
password prompts and suppressing the mail on a successful run. Any
other stderr output, such as command failure, will be passed though by
grep, and produce a mail.

And BTW, Mark, thanks for your hard work on imap-2006!

On Sat, 16 Sep 2006 11:23:17 -0700, Mark Crispin
<mrc@CAC.Washington.EDU> wrote:

>> Hey! How about cron?

> Clever, but I would be a bit uncomfortable about having password in a
> crontab...

Passwords in crontabs are no worse than cleartext passwords in sasldb
or openldap. To have encrypted SASL authentication over the wire, you
have to store cleartext passwords on a host. There are good arguments
for avoiding the overhead of whole channel SSL encryption.


> An expect script is pretty bad too...

From the standpoint of permissions management and control, much worse
than crontabs.

On Sat, 16 Sep 2006, John Kelly wrote:
> So if we can find some way to run our script without a controlling
> terminal, getpass() will grab the password from stdin, and we won't
> need expect.

That's basically how expect works.

> Hey! How about cron?

Clever, but I would be a bit uncomfortable about having password in a
crontab... An expect script is pretty bad too...

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

On Sat, 16 Sep 2006 12:12:33 -0700, Mark Crispin
<mrc@CAC.Washington.EDU> wrote:

>On Sat, 16 Sep 2006, John Kelly wrote:

>> From the standpoint of permissions management and control, much worse
>> than crontabs.

>It all depends upon the script. The one that I used prompted for the
>password, and then used it as it ran the commands in the script. The
>password was only stored in the expect process' memory, and vanished when
>that process vanished.

To avoid user interactivity, the password must be stored somewhere on
disk, otherwise, we are back at square one, and the user must manually
enter the password. I wanted full automation, including entry of the
password.


>I stopped using it once I had Kerberos deployed. Kerberos does not have
>password in the clear on client or server. It is true that the KDC has to
>be secured, but it's much easier to secure one machine than it is to
>secure all the clients and servers. I wish that Kerberos was more widely
>used.

I have no time to learn Kerberos. I'm too busy grubbing for labor
saving scripts ...

On Sat, 16 Sep 2006, John Kelly wrote:
>> An expect script is pretty bad too...
> From the standpoint of permissions management and control, much worse
> than crontabs.

It all depends upon the script. The one that I used prompted for the
password, and then used it as it ran the commands in the script. The
password was only stored in the expect process' memory, and vanished when
that process vanished. Although arguably the password might have showed
up in the swap area of the disk, that's still better than in some file.

I stopped using it once I had Kerberos deployed. Kerberos does not have
password in the clear on client or server. It is true that the KDC has to
be secured, but it's much easier to secure one machine than it is to
secure all the clients and servers. I wish that Kerberos was more widely
used.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

On Sat, 16 Sep 2006 16:56:00 +0100, John Kelly <jak@isp2dial.com>
wrote:

> .... 2>&1 | grep -v '^password: password:'

>That's why I redirect stderr to the "grep -v" pipe, filtering out the
>password prompts and suppressing the mail on a successful run. Any
>other stderr output, such as command failure, will be passed though by
>grep, and produce a mail.

There is a bug in that grep. I assumed error messages would start on
a new line, but that is not true. Here is the fix:

grep -v '^[[:space:]]*password:[[:space:]]*$'

And when I fixed that, then I discovered a warning message from the
server, that I didn't want mails for. So here is the next version:

grep -v 'hasnoatt\|^[[:space:]]*password:[[:space:]]*$'

I may be the only living person who cares about this, but for anyone
who finds this thread in an archaeological dig a thousand years from
now, you may have to tinker with the grep to get it working the way
you want. :-)

"Mark Crispin" <mrc@CAC.Washington.EDU> wrote in message
news:Pine.OSX.4.64.0609161208130.368@pangtzu.panda .com...
> I wish that Kerberos was more widely used.

It is. Active Directory.