home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / os / linux / 20986 < prev    next >
Encoding:
Internet Message Format  |  1992-12-21  |  2.3 KB
  1. Path: sparky!uunet!zaphod.mps.ohio-state.edu!usc!hela.iti.org!cs.widener.edu!eff!world!ksr!zdenek
  2. From: zdenek@ksr.com (Zdenek Radouch)
  3. Newsgroups: comp.os.linux
  4. Subject: ps and /dev/kmem
  5. Message-ID: <20234@ksr.com>
  6. Date: 18 Dec 92 12:01:57 EST
  7. References: <1992Dec18.063831.24368@news.stolaf.edu>
  8. Sender: news@ksr.com
  9. Organization: Kendall Square Research Corp.
  10. Lines: 42
  11.  
  12. >yes, it is "yet another /proc ps".
  13. >
  14. >I took the classic /dev/kmem ps, the perl /proc ps, and the simple c
  15. >/proc ps posted recently, and made one c /proc ps.
  16. >
  17. >The interface and output is that of the /dev/kmem ps, and the guts are
  18. >those of the simple c /proc ps (but majorly revised).  Unfortunately,
  19. >/proc is not quite up to fulfilling the role of /dev/kmem, but if I
  20. >start hacking on the kernel tomorrow, it may come closer ;-)
  21.  
  22. [...]
  23.  
  24. >I just like a ps that doesn't require a
  25. >namelist file, and that doesn't have to be suid or sgid, and is thus
  26. >not a security risk, and doesn't have to be recompiled and updated all
  27. >the time.
  28.  
  29. Most of the modern unix or unix like implementations avoid using
  30. /dev/kmem kind of interface exactly for the above reasons.
  31. In the absence of a standard interface it is still much cleaner
  32. to devise your own kernel interface. When a standard interface is defined
  33. you can either revise your interface, or insert a user space conversion
  34. layer between your interface and the user.
  35.  
  36. It might be OK to keep recompiling user code on a hacker's system,
  37. but any commercial release tries to avoid touching the user code
  38. during system updates.
  39.  
  40. If you want a really BAD example of what happens when one hacks /dev/kmem
  41. look no further than GNUmake. GNUmake needs access to the machine loading info,
  42. and it was designed to retrieve it from /dev/kmem rather than using a generic
  43. module that would retrieve it from wherever it can. This resulted in a design
  44. where GNUmake must run with euid=0 (at least at times that it accesses kmem),
  45. and toggle uid back whenever it touches real files. This is unfortunately
  46. impossible to do with a single executable (you need two, one suid) under POSIX
  47. or Sys V, so GNUmake will not work on these machines. The bad part is that
  48. since the whole /dev/kmem concept was so tightly built in, there is no way
  49. to fix this easily, a fix would require a major redesign and consequently
  50. they (FSF) won't even address this issue.
  51.  
  52. my $.02
  53. -Z
  54.