home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / sys / sun / admin / 8627 < prev    next >
Encoding:
Internet Message Format  |  1992-11-24  |  2.0 KB

  1. Xref: sparky comp.sys.sun.admin:8627 comp.unix.admin:6355 comp.unix.programmer:5414 comp.unix.wizards:4878
  2. Newsgroups: comp.sys.sun.admin,comp.unix.admin,comp.unix.programmer,comp.unix.wizards
  3. Path: sparky!uunet!elroy.jpl.nasa.gov!usc!rpi!batcomputer!theory.TC.Cornell.EDU!mdw
  4. From: mdw@theory.TC.Cornell.EDU (Matt Welsh)
  5. Subject: Re: revisited, determining if anyone else is logged on
  6. Message-ID: <1992Nov24.041110.10320@tc.cornell.edu>
  7. Sender: news@tc.cornell.edu
  8. Nntp-Posting-Host: theory.tc.cornell.edu
  9. Organization: Cornell Theory Center
  10. References: <1992Nov23.234245.18246@mcs.drexel.edu>
  11. Date: Tue, 24 Nov 1992 04:11:10 GMT
  12. Lines: 28
  13.  
  14. In article <1992Nov23.234245.18246@mcs.drexel.edu> usmyrtle@mcs.drexel.edu (Steven Myrtle) writes:
  15. [About finding out users that are logged in without use of "who" et al.]
  16. >Some people have gotten
  17. >closer to what I'm asking for.  They suggested I use system(), fork(),
  18. >execl(), etc., to execute a w, who, finger, etc.  But I don't at all
  19. >consider doing that from within a setuid program to be a good practice,
  20. >and I won't do it.
  21.  
  22. Using execv(), with the complete pathname to the program to exec should be
  23. quite safe. Of course it depends on having "who" or "w", etc. available.
  24. System() has problems because it goes through sh, and you have to deal with
  25. a few rudimentary security issues. I don't think that this is a problem if
  26. you fork() and execv() the new image, even if the program is setuid (because
  27. you're not going through a shell, and the exec'd program should be just as
  28. secure as your own setuid program in the child process). That is, of course,
  29. assuming that the program you're execv'ing doesn't have its own security
  30. problems (which "who" and friends shouldn't). 
  31.  
  32. I don't generally like having programs depend on other system programs,
  33. but for 90% of your applications this shouldn't be a problem at all.
  34.  
  35. But if you want to roll your own, be my guest. :)
  36.  
  37. mdw
  38.  
  39. -- 
  40. Matt Welsh    mdw@tc.cornell.edu        +1 607 253 2737
  41.   "We're going away now. I fed the cat."
  42.