home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / gnu / bash / bug / 551 < prev    next >
Encoding:
Text File  |  1992-08-14  |  3.8 KB  |  98 lines
  1. Newsgroups: gnu.bash.bug
  2. Path: sparky!uunet!convex!darwin.sura.net!zaphod.mps.ohio-state.edu!cis.ohio-state.edu!ihspa.ATt.COM!danj1
  3. From: danj1@ihspa.ATt.COM (Dan Jacobson)
  4. Subject: Re: login should be a builtin
  5. Message-ID: <1992Aug13Th114348a.danj1@ihspa.att.com>
  6. Sender: gnulists@ai.mit.edu
  7. Organization: GNUs Not Usenet
  8. References: <1992Aug7Fr000428a.danj1@ihspa.att.com> 
  9. Distribution: gnu
  10. Date: Thu, 13 Aug 1992 15:43:00 GMT
  11. Approved: bug-bash@prep.ai.mit.edu
  12. Lines: 84
  13.  
  14. >>>>> On Sat, 8 Aug 1992 11:53:07 GMT, jch+@cs.cmu.edu (Jonathan
  15. >>>>> Hardwick) said:
  16.  
  17. JH> danj1@ihspa.ATt.COM (Dan Jacobson) writes
  18. >>>>>>>>>>>>>>>>>>^Like, yo, yo, gnu list maintainers, your e-mail to
  19. news gateway consistently downcases this letter in the "From:" header.
  20.  
  21. > login should be a builtin, because if jimmy, used to some other leading
  22. > brands of shell, does
  23. > bash$ login jenny
  24. > as he turns over the terminal to jenny, and then later jenny logs out
  25. > and walks away, jimmy's bash will be sitting there, so some baddie
  26. > will take advantage of it
  27.  
  28. JH>   [ deleted ]
  29.  
  30. > Plus it's unreasonable to expect jimmy to memorize "'exec login' when
  31. > under bash".
  32.  
  33. JH> It's unreasonable for jenny not to expect a trojan horse when jimmy types
  34. JH>     bash$ login jenny
  35. JH> at his terminal and then says "there you go, it's all yours".  Both
  36. JH> jimmy and jenny appear to be in dire need of a basic computer security
  37. JH> course.  Even something as simple as:
  38. JH>     1. "always log out when you leave your terminal"
  39. JH>     2. "never log in unless you're sure a trojan isn't running"**
  40. JH> would do.  If they can't even master these basic points, they have a
  41. JH> whole heap more trouble to worry about than login not being a builtin
  42. JH> in some shells. 
  43.  
  44. But even if jimmy & jenny are best of trusting friends, the problem is
  45. the 3rd party baddie...
  46.  
  47. JH> Jonathan H.
  48.  
  49. JH> ** For arbitrary definitions of "sure".
  50.  
  51. >>>>> On Sat, 8 Aug 1992 23:47:23 GMT, friedman@gnu.ai.mit.edu (Noah Friedman) said:
  52.  
  53. NF> In article <1992Aug7Fr000428a.danj1@ihspa.att.com> danj1@ihspa.ATt.COM (Dan Jacobson) writes:
  54. >login should be a builtin, because if jimmy, used to some other leading
  55. >brands of shell, does
  56. >bash$ login jenny
  57. >as he turns over the terminal to jenny, and then later jenny logs out
  58. >and walks away, jimmy's bash will be sitting there, so some baddie
  59. >will take advantage of it, and then the whole school will hear some
  60. >rumor that bash is a security hazard.  
  61.  
  62. NF>    I used to feel this way too, but lately I've decided I don't like for
  63. NF> shells to be that clever.  It's even worse for some shells to recognize
  64. NF> "newgrp" and do the same thing they do for login.  It's a misfeature in
  65. NF> those shells. 
  66.  
  67. Thanks for reminding me about that massive drag "newgrp" crap in some
  68. shells, I hereby rescind [withdraw] my original complaint.  One less
  69. special twist for "security" is one more step towards a cleaner shell.
  70.  
  71. >                                        Plus, two out of three selected
  72. >big name shells do it:
  73.  
  74. NF>    "If a million people do a foolish thing, it is still a foolish thing."  :-)
  75.  
  76. >Plus it's unreasonable to expect jimmy to memorize "'exec login' when
  77. >under bash".
  78.  
  79. NF>    If it's really that much of a problem, then I'd suggest putting the
  80. NF> following in /etc/profile:
  81.  
  82. NF>         if [ -n "${PS1}" -a -n "${BASH_VERSION}" ]; then
  83. NF>            alias login='exec login'
  84. NF>         fi
  85.  
  86. Probably best put in a specific parinoid person's .profile.
  87.  
  88. NF> But think about whether you really want to do this, instead of doing the
  89. NF> Right Thing and getting users to learn about how the shell behaves in the
  90. NF> first place.  If the users are lazy even after that, then they can make
  91. NF> their own aliases.
  92.  
  93. Cool, I agree.  [Like, wowsky... I did a 180 degree viewpoint change.]
  94. -- 
  95. danj1@ihspa.att.com (Dan Jacobson) Naperville IL USA
  96. +17089796364 Chinese~{;}5$Da~}Ji1Dan1ni2
  97.  
  98.