home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / sys / sgi / 12460 < prev    next >
Encoding:
Text File  |  1992-08-15  |  1.7 KB  |  48 lines
  1. Newsgroups: comp.sys.sgi
  2. Path: sparky!uunet!munnari.oz.au!mips!mips!sgi!rhyolite!vjs
  3. From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
  4. Subject: Re: shutdown by user
  5. Message-ID: <ojsf4ek@rhyolite.wpd.sgi.com>
  6. Organization: Silicon Graphics, Inc.  Mountain View, CA
  7. References: <2964@accucx.cc.ruu.nl> <o6a8rsk@zuni.esd.sgi.com> <1992Aug13.180112.2505@ctr.com>
  8. Date: Sat, 15 Aug 1992 15:05:44 GMT
  9. Lines: 37
  10.  
  11. In article <1992Aug13.180112.2505@ctr.com>, davids@ctr.com (David Stein) writes:
  12. > In article <165806INNmgs@agate.berkeley.edu> dasilva@eero.ced.berkeley.edu (Ruieta Da Silva) writes:
  13. > >
  14. > >Another way to let anyone shutdown the computer is to create an 
  15. > >account called shutdown and have the .profile or .login 
  16. > >contain 'init 0'. 
  17. > >
  18. > >the passwd entry would look like:
  19. > >shutdown::0:0:shutdown:/usr/people/shutdown:/bin/sh
  20. > >
  21. > >Deanan
  22. > 
  23. > This techique leaves a security hole in it when a user
  24. > uses the su command (ie su shutdown) since by default the 
  25. > .login or .profile is not read by default.  Upon su to shutdown
  26. > the user has superuser privledges, and the system is not halted.
  27.  
  28.  
  29. True, but that hole does not exist if you use a line like
  30.  
  31. shutdown:asdfasdf:0:0:shutdown:/:/etc/halt
  32.  
  33.  
  34. And you need not create any home directories, .login's, etc.
  35.  
  36. Remember that a "shell" is nothing special.  You can use any
  37. arbitrary program or even script that happens to do what you want
  38. as the "shell" for a user.
  39.  
  40. This technique can be used even when the user ultimately needs a
  41. ordinarly shell, but you first need to do security checking.  I think
  42. this is far more secure than putting such security stuff in .login or
  43. /etc/profile, and less intrusive.
  44.  
  45.  
  46.  
  47. Vernon Schryver,  vjs@sgi.com
  48.