As of my STABLE upgrade to the 8:00 GMT Saturday version, I have noticed that ps(1) is behaving differently. Unless run by root, "ps -ax" refuses to print the command line associated with each process. I've checked a couple things: 1. /bin/ps is not SGID kmem and /dev/kmem permission is set to 0640, but that isn't the cause of this problem (though it may cause others, since the ps(1) man page says it needs to read /dev/kmem). 2. /proc/*/cmdline is owned by root:wheel and has 0444 permissions. It should therefore be usable by ps(1) regardless of who runs it. So it looks like command lines should print, but they don't. Does anybody know what's happening here? -- M/S 258-5 |1024-bit PGP fingerprint:|tweten@nas.nasa.gov NASA Ames Research Center | 41 B0 89 0A 8F 94 6C 59| (650) 604-4416 Moffett Field, CA 94035-1000| 7C 80 10 20 25 C7 2F E6|FAX: (650) 604-4377 Not an official NASA position. You can't even be certain who sent this!
At 1:20 PM -0800 3/29/04, Dave Tweten wrote:>As of my STABLE upgrade to the 8:00 GMT Saturday version, I have >noticed that ps(1) is behaving differently. Unless run by root, >"ps -ax" refuses to print the command line associated with each >process.I'll look into it. I did MFC a bunch of changes from current, and it is probably true that I did all my testing on root, so maybe I missed something. -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu
At 1:20 PM -0800 3/29/04, Dave Tweten wrote:>As of my STABLE upgrade to the 8:00 GMT Saturday version, I have >noticed that ps(1) is behaving differently. Unless run by root, >"ps -ax" refuses to print the command line associated with each >process. I've checked a couple things:Now that I have done a complete buildworld, I am seeing about the same behavior. I *do* see the command-args for my own processes, but if run as someone other than root then I don't see the command-args for other people's processes.>1. /bin/ps is not SGID kmem and /dev/kmem permission is set > to 0640, but that isn't the cause of this problem (though > it may cause others, since the ps(1) man page says it needs > to read /dev/kmem).Changing the group and adding 'chmod g+s' does not seem to help. (it would not surprise me if the man page is a little out-of-date, but I don't know that for sure).>2. /proc/*/cmdline is owned by root:wheel and has 0444 permissions. > It should therefore be usable by ps(1) regardless of who runs it.Indeed, my non-root process can 'cat /dev/<pid>/cmdline', but the `ps' command does not try to open those file(s). I imagine it that would be a lot more expensive.>So it looks like command lines should print, but they don't. Does >anybody know what's happening here?The thing is, I also compiled a verison of `ps' that is before my recent barrage of MFC's, and it behaves the same way. In that `ps', ps.c has a version of: $FreeBSD: src/bin/ps/ps.c,v 1.30.2.6 2002/07/04 08:30:37 sobomax Exp $ So, whatever the issue is, it is not related to my recent string of changes to `ps' itself I also noticed: sysctl -a | grep kern.ps kern.ps_strings: 3217031152 kern.ps_arg_cache_limit: 256 kern.ps_argsopen: 1 kern.ps_showallprocs: 1 If I change kern.ps_showallprocs=0 on some older 4.x system, that causes `ps' to behave the way I'm seeing on the latest buildworld. If I change kern.ps_showallprocs=0 on the latest buildworld, the only thing it seems to change is that it stops showing me the command-line for processes where TPGID==0 (more precisely, it changes the output for one 'sshd'-related process). I'm no kernel developer, and I have no spare time, so that's about as far as I can investigate it right now... -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu
drosih@rpi.edu said:>I *do* see the command-args for my own processes, but if run as someone >other than root then I don't see the command-args for other people's >processes.I guess my original statement was a little sloppy. I see exactly what you do. -- M/S 258-5 |1024-bit PGP fingerprint:|tweten@nas.nasa.gov NASA Ames Research Center | 41 B0 89 0A 8F 94 6C 59| (650) 604-4416 Moffett Field, CA 94035-1000| 7C 80 10 20 25 C7 2F E6|FAX: (650) 604-4377 Not an official NASA position. You can't even be certain who sent this!
On Mon, Mar 29, 2004 at 01:20:12PM -0800, Dave Tweten wrote: +> As of my STABLE upgrade to the 8:00 GMT Saturday version, I have noticed +> that ps(1) is behaving differently. Unless run by root, "ps -ax" refuses +> to print the command line associated with each process. I've checked a +> couple things: +> +> 1. /bin/ps is not SGID kmem and /dev/kmem permission is set to 0640, +> but that isn't the cause of this problem (though it may cause +> others, since the ps(1) man page says it needs to read /dev/kmem). +> +> 2. /proc/*/cmdline is owned by root:wheel and has 0444 permissions. +> It should therefore be usable by ps(1) regardless of who runs it. +> +> So it looks like command lines should print, but they don't. Does anybody +> know what's happening here? This is my fault. Fix committed. Sorry for the mess and thank you for your report. -- Pawel Jakub Dawidek http://www.FreeBSD.org pjd@FreeBSD.org http://garage.freebsd.pl FreeBSD committer Am I Evil? Yes, I Am! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20040330/99d86db7/attachment.bin
pjd@FreeBSD.org said:>This is my fault. Fix committed. Sorry for the mess and thank you for your >report.I just finished upgrading to STABLE as of 0800 GMT today. "Ps -ax" is back to working as I expected. Thanks to all for the help. -- M/S 258-5 |1024-bit PGP fingerprint:|tweten@nas.nasa.gov NASA Ames Research Center | 41 B0 89 0A 8F 94 6C 59| (650) 604-4416 Moffett Field, CA 94035-1000| 7C 80 10 20 25 C7 2F E6|FAX: (650) 604-4377 Not an official NASA position. You can't even be certain who sent this!