Last November, I submitted a bug report with patches for nmh - it didn't work
as a POP client properly on Linux systems. But unfortunately, the patches
didn't get into the 1.0.4 release, so here goes again:
The Symptom: Unless .netrc is used, on systems using glibc 2.1.1, 'inc' fails
to work when nmh is configured as a POP client.
The Reason: The glibc version of ruserpass() won't prompt the user for a
password (the glibc maintainers believe that this is the right and proper
behavior, and won't change ruserpass() - see note attached).
Possible Solutions:
1. At minimum, the documentation should be changed to note the current
restriction that ~/.netrc be used to supply a login/password for POP.
2. For Linux systems, avoid using the glibc version of ruserpass(), and use
the version supplied with nmh. There's an additional problem here -
ruserpass() calls getpass(), and in glibc, the getpass() flushes standard input
before prompting the user for a password. When a program like exmh uses 'inc',
it feeds in the password as standard input with code like:
exec inc +inbox -truncate -nochangecur -width 100 << password
which fails with the glibc version of getpass(). So a replacement for
getpass() needs to be provided as well.
What to Do?
I'm willing to put together changes to the nmh configure script that will
use the nmh version of ruserpass(). I have a patch for ruserpass() that works
with my system (see attached). Would you like me to work on the configure
portion?
But it is also the case that 'ruserpass()' is not a "well defined" function -
it's not a Posix function, and can't be guaranteed to exist with any particular
attributes on any particular system. It's an internal routine to rexec(), and
by rights shouldn't really be used by nmh at all. So a better overall fix
would be to always use the nmh version of ruserpass(), including its own
'getpass()' routine, to make sure it always works.
So, what would you like to do? Please at least include a note in the MACHINES
file about the restriction that on Linux systems, ~/.netrc must be used for
POP login/password info. Thanks!
>>>>> glenn writes:
>> Number: 1474
>> Category: libc
>> Synopsis: rexec() function won't prompt for password if not found in .netrc
>file
>> Confidential: no
>> Severity: serious
>> Priority: medium
>> Responsible: libc-gnats
>> State: open
>> Class: sw-bug
>> Submitter-Id: unknown
>> Arrival-Date: Mon Nov 29 12:00:01 EST 1999
>> Last-Modified:
>> Originator: [EMAIL PROTECTED]
>> Organization:
> net
>> Release: 2.1.1
>> Environment:
> Mandrake Linux 6.1, i386 architecture
>> Description:
> Unfortunately, none of this family of functions (rexec, rcmd) is documented in the
>manual.
> Previous editions of ruserpass() in the BSD distribution would prompt for a
> password if it wasn't found in a variety of places. The glibc version will
> only return a username/password if there are appropriate entries in the .netrc file.
> This has caused the current edition of nmh (1.0.2) not to work correctly, because
> it counts on the user being prompted for a password.
> Since there is no documentation of rexec() in the glibc manual, I include for
> reference excerpts from man pages on
This has been discussed several times on the glibc mailing lists. I'm
citing some comments from the discussion:
Mark Kettenis writes on 26th October 1999:
> Do you have any evidence that the statement about rexec asking for the
> username/password is true? Although the BSD man pages do indeed
> mention that rexec() would do this, none of the BSD's derived from
> BSD 4.2 (which according to the man page is the first version that has
> rexec()) do implement this. Since the code in glibc is derived
> directly from BSD, it is no surprise that glibc doesn't do this
> either. So the whole issue appears to be a documentation bug on the
> side of BSD. There may be some reimplementations of rexec() around
> that do ask for a password based on the BSD documentation, but that's
> not very relevant. I think that there are a lot of cases where it is
> unwanted. As a principle, no library call should print anything
> (except when that's the explicit purpose of the call of course), let
> alone ask for input.
And later, Mark again:
>
> Anyway, the issue has been discussed before [1]. Ulrich thinks
> we should stay with the BSD 4.4 implementation, and I agree with him.
> It's more or less the reference standard for rexec().
>
> Also note that rexec() is considered to be pretty dangerous. FreeBSD
> and NetBSD only offer it for compatibility with BSD 4.4, and
> reccommend using another mechanism.
>
> Mark
>
> [1] http://sourceware.cygnus.com/ml/bug-glibc/1999-07/msg00085.html
In a nutshell: glibc follows the BSD 4.4 implementation and we're not
going to change it.
Andreas
--
Andreas Jaeger
SuSE Labs [EMAIL PROTECTED]
private [EMAIL PROTECTED]
*** ruserpass.c.orig Fri Apr 30 14:08:34 1999
--- ruserpass.c Mon Nov 29 14:45:04 1999
***************
*** 178,183 ****
--- 178,210 ----
return(-1);
}
+ #include <termios.h>
+ char *getpass(const char *prompt)
+ {
+ static char buff[50];
+ char *s;
+ struct termios tio, tioO;
+ int in;
+
+ fputs(prompt, stdout);
+ fflush(stdout);
+
+ in = fileno(stdin);
+ tcgetattr(in, &tioO);
+ tio = tioO;
+ tio.c_lflag &= ~ECHO;
+ tcsetattr(in, TCSANOW, &tio);
+
+ s = fgets(buff, sizeof(buff), stdin);
+ if (!s) buff[0] = 0;
+
+ tcsetattr(in, TCSANOW, &tioO);
+
+ if (buff[strlen(buff)-1] == '\n') buff[strlen(buff)-1] = 0;
+
+ return buff;
+ }
+
static int
token(void)
{
