From owner-freebsd-hackers Wed Sep 8 23:55:32 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from users.anet-stl.com (users.anet-stl.com [209.145.150.20]) by hub.freebsd.org (Postfix) with ESMTP id 9452115BE8 for ; Wed, 8 Sep 1999 23:55:30 -0700 (PDT) (envelope-from doogie@anet-stl.com) Received: from x (rhea.jyoung.accessus.net [207.206.158.210] (may be forged)) by users.anet-stl.com (8.9.3/8.8.5) with SMTP id BAA91503; Thu, 9 Sep 1999 01:53:40 -0500 (CDT) From: "Jason Young" To: "Daniel O'Connor" Cc: , , "Gustavo V G C Rios" Subject: RE: CS Project Date: Thu, 9 Sep 1999 01:39:52 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Some further thoughts before I doze off: > > 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 :) After some thought, I think the mount option idea is best. I hadn't thought of that before. One might want to apply different procfs security policies to different mounts of procfs, especially in a jail() situation. Good call. > > 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. I think that the best idea here is a single ps implementation with both backends available. Normally it would use the simple, secure and possibly privacy-enhancing procfs method, but using the -M or -N options to specify a dump or kernel file (or the live /dev/kmem and /kernel, if one were so inclined) would automagically switch ps over to the kvm grovel method. This would make the change transparent to both users and developers. SGID can still be removed - a developer/debugger will already be root or have had to chown the dump/kernel files to do any debugging. It would be mild bloat, but disk is cheap, and a disk space to debugging ease tradeoff has already been made (to the tune of several megs!) by the decision to build debug kernels by default. I agree with that. One could also #ifdef the kvm version. Jason Young accessUS Chief Network Engineer To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message