home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!noc.near.net!hri.com!spool.mu.edu!sdd.hp.com!usc!howland.reston.ans.net!sol.ctr.columbia.edu!eff!world!ksr!zdenek
- From: zdenek@ksr.com (Zdenek Radouch)
- Newsgroups: comp.os.linux
- Subject: Re: ps and /dev/kmem
- Message-ID: <20282@ksr.com>
- Date: 20 Dec 92 19:22:03 GMT
- References: <1992Dec18.063831.24368@news.stolaf.edu> <20234@ksr.com> <1992Dec19.122420.11305@klaava.Helsinki.FI>
- Sender: news@ksr.com
- Organization: Kendall Square Research Corp.
- Lines: 29
-
- I wrote:
- This is unfortunately impossible to do with a single executable (you
- need two, one suid) under POSIX or Sys V, so GNUmake will not work on
- these machines.
-
- >Gee, I had no problem configuring out the load average counting in GNU
- >make. I didn't want it (even under Linux) because of the set_g_id
- >stuff, so I changed the Makefile as indicated in itself, and it
- >worked. Can't imagine why it wouldn't work under POSIX or SYSV.
- >
- >--
-
- Yes, you can configure the loading stuff out, but as I said in my article,
- the problem is that they coded the whole program assuming that it would
- have to toggle uid (to be able to go to /dev/kmem). Unfortunately, they
- didn't understand how the get/setuid() work under POSIX or SystemV so
- the GNUmake will either screw up your permissions or simply fail, if
- you invoke it with uid != euid. The only way to fix it is (assuming
- you don't need to suid) is to edit out all the get/setuid code since
- it can't be disabled.
-
- My point was that not only is /dev/kmem concept and its hacking questionable
- because it requires recompiling, but it also involves complete understanding
- of security issues and definitions of setuid(). Setuid under POSIX and
- SystemV is very complicated and different from BSD setuid.
-
- When I get more time I'll take a look at the linux implementation and
- tell you if it's POSIX compliant.
- -Z
-