From owner-freebsd-smp Sat Dec 16 9:41:55 2000 From owner-freebsd-smp@FreeBSD.ORG Sat Dec 16 09:41:53 2000 Return-Path: Delivered-To: freebsd-smp@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id E546337B400; Sat, 16 Dec 2000 09:41:52 -0800 (PST) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.1/8.11.1) with SMTP id eBGHfke31398; Sat, 16 Dec 2000 12:41:47 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Sat, 16 Dec 2000 12:41:46 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: John Baldwin Cc: smp@FreeBSD.org Subject: Re: cvs commit: src/sys/sys proc.h In-Reply-To: <200012150010.eBF0AX468476@freefall.freebsd.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: robert@fledge.watson.org Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org BTW, I don't know if you've had a chance to look at individual process locking in kern_proc.c yet, but if so then the sysctl code to retrieve process info will need some of the same work during kproc_info extraction (protecting pcred, etc). Also, p_can* will have to assume that the process mutexes for p1 and p2 are both already held (so as to avoid recursion issues), so callers of p_can (especially in procfs and signalling code) will need to reflect that assumption. We should grep through for any direct references to p_cred throughout the tree, and where possible eliminate them by improving authorization abstractions (if I missed any inter-process calls), and where not, make sure they're properly protected and documented (get/set-uid calls, sysctl, etc). Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message