Earlier, Darren Reed more or less suggested getting the kernel to do
the work of getting argv and envp and at the time I didn't think I saw
a need for it.  After a chat to Matt Green, it appears that chasing
process's va to get the argv/envp info is going to be the only reason
for ps to sgid kmem.

So, is there any reasons not to add the equivalent of

	sysctl(CTL_KERN, KERN_PROC_ARGV, pid, buf, len)
and
	sysctl(CTL_KERN, KERN_PROC_ENVP, pid, buf, len)

and completely drop sgid from ps (and probably top and w/uptime as
well)?  This would also remove the need for the current sysctl(CTL_VM,
VM_PROC_VA, pid, va) interface that I'm using at the moment for ps to
get argv's - I can't think of any other users of this interface...

The current envp checks that ps does (only the owner of a process or
root can see the environment) would be kept, and it would be easy to
add similar policy for argv later on if desired.

Any negatives for this approach?  I still need to look at some
implementation issues, such as paging in the pages that contain
the argv for processes that are paged/swaped out.  One question - do
we actually page out struct user at the moment?

Simon.