Sean Eric Fagan wrote:
> In article <[EMAIL PROTECTED]
m> you write:
> > I am all for removing -e, but I don't really like the idea of making
> > it optional nor do I like the idea of trying to maintain the capability
> > for the user's own processes - that simply makes the code even more
> > complex then it already is. The danger is that the option exists in
> > the first place.
>
> I both do and do not want it to be removed.
>
> The code _does not_ need to be more complex, as procfs already implements the
> correct restrictions. (Simply dropping the SGID bit off of ps(1), and
> teaching it to use procfs only, will do it; dropping the SGID bit, and having
> it use /proc/<pid>/mem instead of /dev/kmem, will do the same thing. I
> believe; I don't know ps well enough to figure this all out yet, but that was
> certainly one of my goals when I wrote the bloody thing.)
Well, it's already done. It (ps) hasn't used /dev/kmem for a Very Long
Time. The only thing it used procfs for was the argv, envp and getting
p_stats from the user struct. The code to get p_stats via procfs has been
directly implicated in causing panics and crashes, so it (ps) gets it with
the sysctl it uses to get the rest of the information. The sole user of /
proc in ps now is to get the envp, and ps is no longer setgid. ps now
depends on /proc's permissions enforcement to allow access to /proc/*/mem
for getting envp for processes that the user owns.
Cheers,
-Peter
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
