I recently tried to configure nmh 1.0.2 to work as a POP client on a
Mandrake Linux 6.1 system, which uses glibc 2.1.1, and it didn't work.
The problem is the glibc edition of 'ruserpass.c', which is called by 'inc'
to get the user password. The glibc edition of ruserpass won't prompt the user
for a password, and their policy at present is not to change it (see attached
note).
The first thing that comes to mind is to use the 'ruserpass.c' routine supplied
as part of the compatibility routines with nmh. This is not enough, at
least if one wants 'nmh' to work with 'exmh'. The nmh version of ruserpass.c
uses a standard Unix function called 'getpass()' to pick up the password from
the use. However, the glibc version of 'getpass()' flushes standard input
before prompting the user for a password. So, since exmh uses code like:
exec inc +inbox -truncate -nochangecur -width 100 << password
it can't work, since the glibc getpass() function throws the password string
away before issuing the prompt.
I threw together this patch for nmh/sbr/ruserpass.c that works for inc with
exmh:
*** ruserpass.c.orig Fri Apr 30 14:08:34 1999
--- ruserpass.c Mon Nov 29 13:57:58 1999
***************
*** 178,183 ****
--- 178,196 ----
return(-1);
}
+ char *getpass(const char *prompt)
+ {
+ static char buff[50];
+ char *s;
+
+ s = fgets(buff, sizeof(buff), stdin);
+ if (!s) buff[0] = 0;
+
+ if (buff[strlen(buff)-1] == '\n') buff[strlen(buff)-1] = 0;
+
+ return buff;
+ }
+
static int
token(void)
{
This is not a good permanent solution. The function 'ruserpass()' is not
a standard Unix function, and is in fact an internal routine for the C library,
and one can't expect its function to be constant among different systems.
Portable code would avoid its use.
Since these days the MH functions are 'backend' routines to GUI frontends, it
would be much better to provide command line arguments for the password.
There are other places in the nmh code where ruserpass is used:
mhbuildsbr.c, mhparse.c, msgchk.c, popi.c - so these places should be changed
as well.
>>>>> 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]
