Subject: Using the kernel to get argv for a process.
To: None <email@example.com>
From: Simon Burge <firstname.lastname@example.org>
Date: 04/28/2000 00:24:25
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)
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?