From owner-freebsd-current  Thu Nov 18 20:55:41 1999
Delivered-To: freebsd-current@freebsd.org
Received: from overcee.netplex.com.au (overcee.netplex.com.au [202.12.86.7])
	by hub.freebsd.org (Postfix) with ESMTP id 13F0E155E8
	for <current@freebsd.org>; Thu, 18 Nov 1999 20:55:31 -0800 (PST)
	(envelope-from peter@netplex.com.au)
Received: from netplex.com.au (localhost [127.0.0.1])
	by overcee.netplex.com.au (Postfix) with ESMTP id 332DD1CA0
	for <current@freebsd.org>; Fri, 19 Nov 1999 12:55:29 +0800 (WST)
	(envelope-from peter@netplex.com.au)
X-Mailer: exmh version 2.0.2 2/24/98
To: current@freebsd.org
Subject: Re: PATCH for testing 
In-reply-to: Your message of "Thu, 18 Nov 1999 17:23:58 PST."
             <199911190123.RAA20184@kithrup.com> 
Date: Fri, 19 Nov 1999 12:55:29 +0800
From: Peter Wemm <peter@netplex.com.au>
Message-Id: <19991119045529.332DD1CA0@overcee.netplex.com.au>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

Sean Eric Fagan wrote:
> In article <199911190104.RAA88682.kithrup.freebsd.current@apollo.backplane.co
    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 majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message