From owner-freebsd-hackers Wed Sep 8 23:24: 0 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from cain.gsoft.com.au (genesi.lnk.telstra.net [139.130.136.161]) by hub.freebsd.org (Postfix) with ESMTP id 2910E156C4 for ; Wed, 8 Sep 1999 23:23:53 -0700 (PDT) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (doconnor@cain [203.38.152.97]) by cain.gsoft.com.au (8.8.8/8.8.8) with ESMTP id PAA22975; Thu, 9 Sep 1999 15:53:26 +0930 (CST) (envelope-from doconnor@gsoft.com.au) Message-ID: X-Mailer: XFMail 1.3 [p0] on FreeBSD X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="_=XFMail.1.3.p0.FreeBSD:990909155325:656=_"; micalg=pgp-md5; protocol="application/pgp-signature" In-Reply-To: Date: Thu, 09 Sep 1999 15:53:25 +0930 (CST) From: "Daniel O'Connor" To: Jason Young Subject: RE: CS Project Cc: chris@calldei.com, freebsd-hackers@FreeBSD.ORG, Gustavo V G C Rios Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This message is in MIME format --_=XFMail.1.3.p0.FreeBSD:990909155325:656=_ Content-Type: text/plain; charset=us-ascii On 09-Sep-99 Jason Young wrote: > > Hack ps and turn off procfs :) > I would think it more appropriate to adjust procfs' permissions in the > kernel such that a user couldn't look at processes they don't own, > i.e., can't cd or look into /proc/$PIDTHEYDONTOWN. Adding group-read > for wheel or operator or a special new group would be good for things > that must see all the processes. Like this: Well.. that doesn't sound *too* complex either. Would make an interesting CS project :) > queried by an unpriveleged user (chdir to /proc/$PIDEXISTSBUTNOTYOURS > would return ENOENT instead of EACCES), you deny brute force attacks > to find out if a PID exists and by who it is owned. That increases > privacy a bit. Yes. it depends on your level of paranoia. > After all that, one could implement a 'ps' command that would use only > procfs for process info. Procfs would need to export some more info, I It would be a good idea anyway.. I think someone has one floating around anyway. > allowed to. This should be controlled by sysctls like (placement based > on nfs and ffs sysctl placement precedent): Or even a mount option to procfs :) > I think the idea (of a procfs ps) was shot down on the lists some time > ago because ps needs to retain the ability to look at the process list > in a kernel coredump. IMHO that's a lot of messy kvm groveling and > associated kernel-to-userland sync dependencies, just to cater to the > (generous figure) 0.5% of the people out there who have 1) a crashing > FreeBSD box and 2) the expertise and the will to debug the crash dump. > I think that issue needs to be revisited somehow. Well.. I do use crash dumps, but rarely use ps on them.. Even so you could have 2 implementations of ps, or a ps which allows you to compile in a different 'back end'. That way you can use either easily. > Unfortunately I don't have my proposal written in diff(1) at the > moment, but writing all this out makes me really want to go ahead and > do it. Then again, somebody DID ask for a CS project. :) Heh :) --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum --_=XFMail.1.3.p0.FreeBSD:990909155325:656=_ Content-Type: application/pgp-signature -----BEGIN PGP MESSAGE----- Version: 2.6.3ia iQCVAwUBN9dSXVbYW/HEoF9pAQHYSgQAlC2MSFxCsIQFDXeBV9ohTuhFvnvVbu2r oETuLRH0sTZYO5KWtKmC99QFdGWwKvSPiBagg6U4kkWrOhQFCdQuL4WjXQwgkiUF swIRfM2WUW+gbAj/V/p6X4beievtFXjs5I0ranfXlM8QM4atCgt9pMU2IUfKcCOT PCllYG+7ESs= =sXPQ -----END PGP MESSAGE----- --_=XFMail.1.3.p0.FreeBSD:990909155325:656=_-- End of MIME message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message