rcpt@tuegate.tue.nl (Piet Tutelaers) (05/29/90)
The next program shows a bug I encountered in ULTRIX 3.1 when I tried to
install npasswd(1), a public replacement for passwd(1). The password should
obviously not be echo'ed when typed in by the user. To realise this the
program npasswd(1) uses ioctl() calls. The next program compiled with the
compile time flag -DULTRIX_BUG shows the essential part of npasswd(1) that
handles the disabling of the echoing. The program comes up with the next
error message:
getpass(save get): Not a typewriter
By trial and error we find out that the old fashioned gtty() and stty()
calls corrects the ill behaviour of the program (the shown message and no
echoing if the errors are ignored). This can be demonstrated by compiling
the program without the `-DULTRIX_BUG' option.
I consider this as a BUG, perhaps a known one. I would like to know if
ULTRIX 4.0 solves this problem? Who can test this?
-- Piet
rcpt@urc.tue.nl
------------------------------------noecho.c---------------------------
#include <errno.h>
#include <ctype.h>
#include <sys/types.h>
#include <sys/sgtty.h>
#include <stdio.h>
#include <fcntl.h>
#include "version.h"
char pbuf[16]; /* Password read buffer 1 */
/*
* passwd - change the password for a user.
*
* This program impliments the 'passwd' command.
*/
main(argc, argv)
int argc;
char *argv[];
{
void getpass();
getpass("New password: ");
}
struct sgttyb saved_tty_mode;
#define ERR -1
/*
* The system getpass() throws away all but the first 8 characters
* of a password string. If this isn't enough for you, use this
* routine instead. This code assumes that stdin is the terminal.
*/
void getpass(prompt)
char *prompt;
{
struct sgttyb saved, /* Saved tty characteristics */
noecho; /* No-echo tty characteristics */
char *index();
int tp;
static char ib[64]; /* Input buffer */
char *rc; /* Temp */
if ((tp = open("/dev/tty", O_RDONLY)) < 0)
{
perror("getpass(open)");
return;
}
#ifdef ULTRIX_BUG
if (ioctl(tp, TIOCGETP, &saved)==ERR)
{
perror("getpass(save get)");
return;
}
#else
gtty(tp, &saved);
#endif
#ifdef ULTRIX_BUG
if (ioctl(tp, TIOCGETP, &noecho)==ERR)
{
perror("getpass(noechoget)");
return;
}
#else
gtty(tp, &noecho);
#endif
noecho.sg_flags &= ~ECHO;
#ifdef ULTRIX_BUG
if (ioctl(tp, TIOCSETP, &noecho)==ERR)
{
perror("getpass(noecho set)");
return;
}
#else
stty(tp, &noecho);
#endif
fputs(prompt, stderr);
#ifdef ULTRIX_BUG
rc = fgets(ib, sizeof(ib), stdin);
#else
rc = read(tp, (char *)ib, (int) sizeof(ib));
#endif
putc('\n', stderr);
#ifdef ULTRIX_BUG
(void) ioctl(tp, TIOCSETP, &saved);
#else
stty(tp, &saved);
#endif
close(tp);
fprintf(stderr, "password was:%s\n", ib);
}pilmeyer@utrtsc.dec.com (Han Pilmeyer) (05/30/90)
Piet, I've ran the noecho program (compiled with -DULTRIX_BUG) on several ULTRIX systems. ULTRIX versions include V3.0 and V3.1 on both VAX and RISC. I'm not getting error messages, and there is no echo for what I type. -Han.
rcpt@tuegate.tue.nl (Piet Tutelaers) (06/04/90)
pilmeyer@utrtsc.dec.com (Han Pilmeyer) writes: >I've ran the noecho program (compiled with -DULTRIX_BUG) on several ULTRIX >systems. ULTRIX versions include V3.0 and V3.1 on both VAX and RISC. >I'm not getting error messages, and there is no echo for what I type. The bug I have reported is because I used gcc (version 1.36), without verifying, I supposed that the bug would also exist in native Ultrix compilers. I have checked cc(1) on VAX (Ultrix 3.0) and MIPSEL (Ultrix 3.1) and indeed: no runtime error and no echo! Thanks Han. There is one saying: ``Don't jump to conclusions''. I am very sorry I did not obey this advice. Perhaps the error should be reported elsewhere? --Piet
mathisen@dali.cs.montana.edu (Jaye Mathisen) (06/04/90)
In article <1772@tuegate.tue.nl> rcpt@tuegate.tue.nl (Piet Tutelaers) writes: >pilmeyer@utrtsc.dec.com (Han Pilmeyer) writes: >>I've ran the noecho program (compiled with -DULTRIX_BUG) on several ULTRIX >>systems. ULTRIX versions include V3.0 and V3.1 on both VAX and RISC. > >>I'm not getting error messages, and there is no echo for what I type. > >The bug I have reported is because I used gcc (version 1.36), without >verifying, I supposed that the bug would also exist in native Ultrix > >Perhaps the error should be reported elsewhere? The installation instructions for gcc mention that you need to run the fixincludes script supplied with gcc to patch up the ioctl.h header file. I think you can also use the -traditional flag to gcc and it will work. or use the system supplied C preprocessor, and let gcc at it after it's been run through /usr/lib/cpp. Anyway, tell your sysadmin to run fixincludes.
frank@croton.enet.dec.com (Frank Wortner) (06/04/90)
> The bug I have reported is because I used gcc (version 1.36), without > verifying, I supposed that the bug would also exist in native Ultrix > compilers. I have checked cc(1) on VAX (Ultrix 3.0) and MIPSEL (Ultrix 3.1) > and indeed: no runtime error and no echo! Thanks Han. It's a known problem. The ULTRIX OS header files are not written in ANSI C --- the same is true of most U**X-derived software. The biggest offenders are constructs like: #define foo(a) ('a') Old C compilers would output ('b') when given foo(b) as input. An ANSI compiler will output ('a') Header files are being rewritten. GCC comes with a script called "fixincludes" which attempts to find and repair this and other problems. You should check to see if 1) it was run, and 2) if fixincludes was run, that it did the job completely and correctly. Regards, Frank