> For all of these, I think the right thing is to extend the proc
> server. The point of proc_getprocinfo is to provide "whatever ps
> needs".
Ok. I'm not going to worry about ids for the moment.
For libps the most obvious thing is to add task_events_info to procinfo.
I'll do that. In fact, shazzam, I did it. I hope nobody minds that I
changed the layout of struct procinfo just now.
The more problematic cases are the ones for which it gets the task port to
authenticate a msg_get_* RPCs to the process being examined. These are:
PSTAT_UMASK -- Nothing actually uses it!
But it would make sense to add a %umask spec.
However, there is no reason non-owners should be able to
see it, so we don't need ps setuid for this.
PSTAT_CWDIR -- Ditto.
However, current BSD and Linux ps do not let you see the
cwd of processes you don't own, and Linux's /proc
doesn't either (though 4.3BSD's ps d would show you).
So it would be ok for this spec not to work for random
users using ps on other users' processes.
PSTAT_AUTH -- Nothing uses this either. ps just shows the process owner.
It might be useful to display the full ID sets, but that
could be returned by the proc server.
PSTAT_CTTYID -- Needed to figure out each process's tty.
So the only case that really remains for consideration is the cttyid port.
ps needs this to be able to determine the tty to print for a process. The
only place that ever knows it (or really should) is libc, so the message
port RPC is the only way to fetch it. It's up to each process (i.e. the
libc code) to decide who it lets ask for what ports. It could decide to
give out its cttyid port to anyone who asks. But that gives away the port
to users who could not otherwise get it (you have to be able to open the
tty for either read or write to get the cttyid port from it), and with the
cttyid port you can open the tty for O_RDWR.
_______________________________________________
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
