home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / os / linux / 17164 < prev    next >
Encoding:
Internet Message Format  |  1992-11-18  |  3.2 KB
  1. Path: sparky!uunet!utcsri!newsflash.concordia.ca!clyde.concordia.ca!altitude!Nyongwa.CAM.ORG!steve
  2. From: steve@Nyongwa.CAM.ORG (Steve M. Robbins)
  3. Newsgroups: comp.os.linux
  4. Subject: Re: Fix for getty/uugetty under pl5
  5. Summary: mea culpa -- patch included
  6. Message-ID: <Bxy417.BqB@Nyongwa.CAM.ORG>
  7. Date: 19 Nov 92 04:19:53 GMT
  8. References: <1992Nov18.011322.9917@galileo.cc.rochester.edu>
  9. Organization: Chiral Symmetry Breaking, Inc.
  10. Lines: 72
  11.  
  12. In article <1992Nov18.011322.9917@galileo.cc.rochester.edu> ctne_ltd@uhura.cc.rochester.edu (Chris Newbold) writes:
  13. >I've found the problem with the getty/uugetty from getty_ps203.
  14. >
  15. >The culprit is the code which attempts to add an entry into utmp
  16. >for uugetty. Notice that the ifdef explicitly excludes the code
  17. >which initializes utmp; the subsequent strncopys try to copy 
  18. >stuff to a NULL structure:
  19. >
  20. >From main.c:585:
  21. >
  22. >#ifndef linux
  23. >        while ((utmp = getutent()) != (struct utmp *) NULL) 
  24. >                if (utmp->ut_type == INIT_PROCESS && utmp->ut_pid == pid)
  25. >#endif
  26. >                        {
  27. >                        debug2(D_UTMP, "logutmp entry made\n");
  28. >                        /* show login process in utmp
  29. >                         */
  30. >                        strncopy(utmp->ut_line, Device);
  31. >                        strncopy(utmp->ut_id, Device+3);
  32.  
  33. Ooops.  That was stupid, wasn't it?
  34.  
  35. >I don't know enough about this to say what the real fix is (maybe
  36. >it should be "#ifdef", I dunno. Perhaps the person who did the 
  37. >original port can comment.
  38.  
  39. Okay, the reason I #ifdef'd out the loop to search through utmp was that
  40. the init (simpleinit from poe) that I have does not create INIT_PROCESS
  41. entries.  The result is that the loop here never finds an entry, and doesn't
  42. overwrite it.  So the last person to use the line will *always* show up in
  43. 'who' until someone else logs in, because 'login' doesn't bother checking --
  44. it ALWAYS writes a utmp entry.
  45.  
  46. Poe's getty did no utmp checking, so I copied him.  And I goofed.
  47. The fix is then to malloc the memory for utmp before trying to use it.
  48. (Is the real fix to have init write INIT_PROCESS entries?)
  49.  
  50. Now: can someone explain why it took until pl5 for this to show up?  Since the
  51. pointer utmp is a local variable to function main(), doesn't it have the
  52. value 0?  If it does, how come writing all this junk to location zero doesn't
  53. overwrite other valuable things and just crash royally?
  54.  
  55. Here's my aforementioned patch:
  56.  
  57. ---------------------------------------------------------------------------
  58. *** main.old    Wed Nov 18 22:50:05 1992
  59. --- main.c    Wed Nov 18 23:02:55 1992
  60. ***************
  61. *** 579,585 ****
  62.       debug2(D_RUN, "update utmp/wtmp files\n");
  63.   
  64.       pid = getpid();
  65. ! #ifndef linux
  66.       while ((utmp = getutent()) != (struct utmp *) NULL) 
  67.           if (utmp->ut_type == INIT_PROCESS && utmp->ut_pid == pid)
  68.   #endif
  69. --- 579,587 ----
  70.       debug2(D_RUN, "update utmp/wtmp files\n");
  71.   
  72.       pid = getpid();
  73. ! #ifdef linux
  74. !     if ((utmp = malloc(sizeof(struct utmp))) != NULL)
  75. ! #else
  76.       while ((utmp = getutent()) != (struct utmp *) NULL) 
  77.           if (utmp->ut_type == INIT_PROCESS && utmp->ut_pid == pid)
  78.   #endif
  79. ---------------------------------------------------------------------------
  80.  
  81. -- 
  82. Steve Robbins  --  steve@nyongwa.cam.org
  83. %SYSTEM-F-ANARCHISM, the operating system has been overthrown
  84.