From owner-freebsd-current Mon Feb 3 9:58: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 7946337B401 for ; Mon, 3 Feb 2003 09:58:15 -0800 (PST) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id BA91F43F75 for ; Mon, 3 Feb 2003 09:58:14 -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 h13Hw5P4082062; Mon, 3 Feb 2003 12:58:05 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Mon, 3 Feb 2003 12:58:05 -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: <20030203090133.R78581-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 Mon, 3 Feb 2003, Ilmar S. Habibulin wrote: > Why not to use only credits for proc and make td_ucred macro like > td_proc->p_ucred? Or it has some meaning that i do not understand? td_ucred is a cached copy of p_ucred. The cached copy is potentially updated on any entry to the kernel. The reason for doing this is multi-fold: (1) Because of threading, access to p_ucred requires holding the process lock. Because we don't want to hold the process lock for every access control check, using a thread-access only reference avoids the lock. (2) Credential consistency. We perform the update check when we enter the kernel; if the comparison indicates they differ, we grab the process lock and update td_ucred. If they don't differ, we can continue. My understanding is that this is because a pointer comparison to determine if they are identical is permitted without a lock. It might be desirable to reason about the safety of this. This guarantees a single consistent "process credential" for each system call; that way there aren't races between separate access control checks resulting in inconsistent enforcement. So the end semantic is that there is, in effect, a single process credential. However, there may be divergence from that credential when threads are blocked in kernel and another thread changes the process credential, as the threads blocked in kernel won't pick up the new credential until they exit and re-enter the kernel. This approach, as I understand it, is taken by several other MP/threaded UNIXes. 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. 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