ps doesn't need privileges?
Please don't flame me if I'm asking something stupid, but I'm a bit confused. I always thought that /bin/ps needs to be setgid kmem to be able to display the process list. And this in fact seems to be the fact under 2.2.8: /home/blaz uname -a FreeBSD server.amis.net 2.2.8-RELEASE FreeBSD 2.2.8-RELEASE #0: Mon Dec 14 19:22:23 CET 1998 [EMAIL PROTECTED]:/usr/src/sys/compile/SERVER i386 /home/blaz ls -la /bin/ps -r-xr-sr-x 1 bin kmem 176128 Oct 26 1998 /bin/ps /home/blaz cp /bin/ps /tmp /home/blaz ls -la /tmp/ps -r-xr-xr-x 1 blaz bin 176128 Sep 11 14:08 /tmp/ps /home/blaz /tmp/ps ax ps: /dev/mem: Permission denied As expected, a copy of ps without setgid kmem can't display the process list. But under 3.2 and higher, it is! Here is what happens under 4.0-CURRENT (same thing under 3.2): /home/blaz uname -a FreeBSD gold.amis.net 4.0-CURRENT FreeBSD 4.0-CURRENT #0: Sat Sep 4 19:03:23 CEST 1999 [EMAIL PROTECTED]:/home/blaz/FreeBSD/src/sys/compile/GOLD i386 /home/blaz ls -la /bin/ps -r-xr-sr-x 1 root kmem 197820 Aug 7 12:42 /bin/ps* /home/blaz cp /bin/ps /tmp /home/blaz ls -la /tmp/ps -r-xr-xr-x 1 blaz wheel 197820 Sep 11 14:09 /tmp/ps* /home/blaz /tmp/ps ax PID TT STAT TIME COMMAND 0 ?? DLs0:00.00 (swapper) 1 ?? ILs0:00.00 (init) 2 ?? DL 0:00.00 (pagedaemon) 3 ?? DL 0:00.00 (vmdaemon) 4 ?? DL 0:00.00 (bufdaemon) .etc. What am I missing? How is a totally unprivileged process able to display a list of processes? Blaz Zupan, [EMAIL PROTECTED], http://www.herbie.amis.net Medinet d.o.o., Linhartova 21, 2000 Maribor, Slovenia To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ps doesn't need privileges?
On Sat, Sep 11, 1999, Blaz Zupan wrote: What am I missing? How is a totally unprivileged process able to display a list of processes? Please give me the output of ``ls -l /dev/kmem'' and ``id'' -- |Chris Costello [EMAIL PROTECTED] |Foolproof operation: All parameters are hard coded. ` To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ps doesn't need privileges?
On Sat, 11 Sep 1999, Chris Costello wrote: Please give me the output of ``ls -l /dev/kmem'' and ``id'' /home/blaz id uid=1000(blaz) gid=1000(users) groups=1000(users) /home/blaz ls -l /dev/kmem crw-r- 1 root kmem2, 1 May 23 15:26 /dev/kmem Blaz Zupan, [EMAIL PROTECTED], http://www.herbie.amis.net Medinet d.o.o., Linhartova 21, 2000 Maribor, Slovenia To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ps doesn't need privileges?
On Sat, Sep 11, 1999, Blaz Zupan wrote: /home/blaz id uid=1000(blaz) gid=1000(users) groups=1000(users) /home/blaz ls -l /dev/kmem crw-r- 1 root kmem2, 1 May 23 15:26 /dev/kmem Oh. ps doesn't use /dev/kmem. Look at a ktrace of it; it works just as it should. /tmp/ps auwwx prints what it should and the ktrace output shows it opens the processes whose memory it can read (as ``nobody'' I could read httpd processes, my ksh process and my ps process) and errors for those it cannot: 8290 ps CALL __sysctl(0xbfbfc944,0x4,0xbfbfc954,0xbfbfc940,0,0) 8290 ps RET __sysctl 0 8290 ps CALL open(0xbfbfc878,0,0) 8290 ps NAMI "/proc/7997/mem" 8290 ps RET open -1 errno 13 Permission denied 8290 ps CALL close(0x) 8290 ps RET close -1 errno 9 Bad file descriptor -- |Chris Costello [EMAIL PROTECTED] |CCITT - Can't Conceive Intelligent Thoughts Today `- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ps doesn't need privileges?
Chris Costello wrote: On Sat, Sep 11, 1999, Blaz Zupan wrote: /home/blaz id uid=1000(blaz) gid=1000(users) groups=1000(users) /home/blaz ls -l /dev/kmem crw-r- 1 root kmem2, 1 May 23 15:26 /dev/kmem Oh. ps doesn't use /dev/kmem. Look at a ktrace of it; it works just as it should. /tmp/ps auwwx prints what it should and the ktrace output shows it opens the processes whose memory it can read (as ``nobody'' I could read httpd processes, my ksh process and my ps process) and errors for those it cannot: 8290 ps CALL __sysctl(0xbfbfc944,0x4,0xbfbfc954,0xbfbfc940,0,0) 8290 ps RET __sysctl 0 8290 ps CALL open(0xbfbfc878,0,0) 8290 ps NAMI "/proc/7997/mem" 8290 ps RET open -1 errno 13 Permission denied 8290 ps CALL close(0x) 8290 ps RET close -1 errno 9 Bad file descriptor Not quite. It uses sysctl(2) to grab the eproc table, which contains most of the data. It then uses procfs to get things like the command arguments (which have to come from the process address space) and so on. It also means that ps can see your *own* processes and their full command args: /tmp/ps -aux peter 63399 0.0 0.1 600 256 pt Is+ 6:46PM 0:00.01 /bin/sh /home/pe root63402 0.0 0.5 1544 1160 pt I+ - 0:00.00 (ssh1) nobody 68421 0.0 0.6 4240 1428 ?? I- 0:00.00 (apache) root68535 0.0 1.5 4588 3744 ?? I- 0:00.00 (xterm) peter 68536 0.0 0.4 1492 1076 pu Is8:44PM 0:00.10 -csh (tcsh) peter 98319 0.0 0.4 1412 1096 p8 T10:14PM 0:00.05 vi sb.c peter 98893 0.0 0.4 1412 1096 pu I+ 12:38AM 0:00.30 vi asm.h peter 98997 0.0 0.4 1404 1060 pd I+1:11AM 0:00.10 vi swtch.s postfix 99059 0.0 0.2 884 564 ?? I- 0:00.00 (pickup) in the example above, my processes are visible but non-peter ones are just their basename. Now that I think about it, it shouldn't be too hard (TM) to finish off the /proc/pid/cmdline stuff so that ps didn't need to access /mem and didn't need setgid at all. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ps doesn't need privileges?
On Sun, Sep 12, 1999, Peter Wemm wrote: Now that I think about it, it shouldn't be too hard (TM) to finish off the /proc/pid/cmdline stuff so that ps didn't need to access /mem and didn't need setgid at all. What about the `e' flag? -- |Chris Costello [EMAIL PROTECTED] |Computers... are not designed, as we are, for ambiguity. - Thomas `--- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ps doesn't need privileges?
Ok, sorry for the wasted bandwidth. I found it. I should have read the commit logs more carefully. :( revision 1.25 date: 1998/06/30 21:34:14; author: phk; state: Exp; lines: +10 -4 branches: 1.25.2; Pick up kernel variables/constants using sysctl rather than through /dev/mem Use /dev/null for opening the kvm library, we don't need access to /dev/mem anymore. ps can now run without the setgid(kmem) bit. If it does it will not be able to show argv/envp for another uid's processes unless you are root. Blaz Zupan, [EMAIL PROTECTED], http://www.herbie.amis.net Medinet d.o.o., Linhartova 21, 2000 Maribor, Slovenia To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ps doesn't need privileges?
Chris Costello wrote: On Sun, Sep 12, 1999, Peter Wemm wrote: Now that I think about it, it shouldn't be too hard (TM) to finish off the /proc/pid/cmdline stuff so that ps didn't need to access /mem and didn't need setgid at all. What about the `e' flag? I'm of the opinion that this particular beastie should be restricted to seeing your own processes only (unless you're root). Implementing /proc/pid/cmdline (globally readable) and /proc/pid/environ (user, group kmem readable only), and turning off setgid kmem for ps. I've lost count of the number of things that want you to do things like: setenv CVSPASSWORD foo etc. Cheers, -Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ps doesn't need privileges?
In message [EMAIL PROTECTED], Chris Costello wrote: } On Sun, Sep 12, 1999, Peter Wemm wrote: } Now that I think about it, it shouldn't be too hard (TM) to finish off the } /proc/pid/cmdline stuff so that ps didn't need to access /mem and didn't } need setgid at all. } }What about the `e' flag? What about people who don't use /proc? Maybe I'm misreading; is the plan to make ps work (at least with most of the bells and whistles) only with /proc, or is the plan to make it an option to either strip the setgid and use proc, or to leave it and use kmem? -- Jon Hamilton [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
