From owner-freebsd-arch Mon Dec 11 14:10:10 2000 From owner-freebsd-arch@FreeBSD.ORG Mon Dec 11 14:10:07 2000 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (Postfix) with ESMTP id 8D7A037B400; Mon, 11 Dec 2000 14:10:07 -0800 (PST) Received: (from daemon@localhost) by smtp02.primenet.com (8.9.3/8.9.3) id PAA25135; Mon, 11 Dec 2000 15:05:23 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp02.primenet.com, id smtpdAAAnca49W; Mon Dec 11 15:05:17 2000 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id PAA29128; Mon, 11 Dec 2000 15:09:57 -0700 (MST) From: Terry Lambert Message-Id: <200012112209.PAA29128@usr08.primenet.com> Subject: Re: Can !curproc touch To: jhb@FreeBSD.ORG (John Baldwin) Date: Mon, 11 Dec 2000 22:09:57 +0000 (GMT) Cc: arch@FreeBSD.ORG In-Reply-To: from "John Baldwin" at Dec 11, 2000 01:53:20 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: tlambert@usr08.primenet.com Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I've got a question about p_cred in proc, specifically p_cred->pc_ucred. In > several VOP's and other places we use p_cred->pc_ucred (aka p_ucred) as the > credentials if we don't already have one. The problem arises if another > process can crfree() that ucred either by a crcopy() or a direct crfree() of > p_ucred. I would suggest that credential instances are established separately from their use. Ideally, if I am logged in 5 places, I have exactly one instance of my credentials structure lying around. This is much more important for things like a fixed SMBFS, which uses per-user credentials across the mount in order to establish per user zccess controls, enforced by the server (the current mount can not do this, since there is no way for the kernel to query a user session about credentials). In this case, you'd expect that a credenital would be something like: struct mycred { struct mycred *nextcred; char *nonce; void *cred_for_nonce; }; When one of my login instances authenticates to a particular credential requiring system, represented by a particular nonce, then all should be authenticated (I am authenticating to the system, not to a session instance; consider an X session with multiple xterm's, where each xterm does not require seperate authentication). What this basically means is that you need a lock, or use an atomic operation, in order to maintain a reference count on the credential object. When a function enters on to dereference the credential pointer, it acquires a reference. The only remaining houskeeping is setting the reference count to one when the credential is instanced, and deleting it on the 1->0 reference transition. A lot of the issues having to do with SMP references should be handled this way; so should the vnode issues (e.g. when a vnode is referenced by the directory lookup cache, the cache should hold a reference to it; each open instance should similarly hold a reference to it, etc.). You aren't trying to protect if from manipulation, once it is established (manipulation would require a light weight lock held over the manipulation event, if it were a common case; better to set the lock only on a multiply referenced object (e.g., have something like a "has_alias" flag, and if it's not set, ignore the locking, while requiring the lock to change the flag; since the operation is atomic, and you guarantee ordering, where the lock is held, the flag is set, the lock is released, the lock is acquired for other manipulation or reading now the flag is set... you are safe to do a quick test, and unaliased operations proceed quickly). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message