From owner-freebsd-current Tue Feb 4 5: 8:17 2003 Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0161337B401 for ; Tue, 4 Feb 2003 05:08:16 -0800 (PST) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6362043F75 for ; Tue, 4 Feb 2003 05:08:15 -0800 (PST) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.12.6/8.12.5) with SMTP id h14D83P4018114; Tue, 4 Feb 2003 08:08:03 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Tue, 4 Feb 2003 08:08:02 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: "Ilmar S. Habibulin" Cc: freebsd-current@freebsd.org Subject: Re: What is the difference between p_ucred and td_ucred? In-Reply-To: <20030204032624.U9181-100000@fledge.watson.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, 4 Feb 2003, Ilmar S. Habibulin wrote: > On Mon, 3 Feb 2003, Robert Watson wrote: > > > The strategy for selecting a credential to check against is generally to > > use td_ucred, and to hold no locks. You'll see that suser() does this, > > for example. Under some circumstances: specifically, credential updates, > > you need to hold the process lock and atomically check the process > > credential before updating. If the thread doesn't immediately leave the > > kernel (i.e., more checks might be performed), you'll also need to > > propagate the cred change to the thread from the process. > > Ok. Thank you for an expanation, I'll consider that. Now i'm trying to > reanimate Thomas Moestls' capability work. Is anybody interested in such > integration? I have almost bootable kernel and now will try to > understand kernel structures locking and td_ucred/p_ucred interactions, > to make nessesary changes. > > Or SEBSD make capabilities completly unnesessary? We have tentative plans to support Capabilities-like models via a plug-in module using the MAC Framework sometime over the next few months. Slotting the POSIX.1e capabilities work into that makes a lot of sense. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Network Associates Laboratories To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message