From owner-freebsd-arch Tue Aug 6 12:51:59 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8AAC737B400; Tue, 6 Aug 2002 12:51:51 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5EC0A43E4A; Tue, 6 Aug 2002 12:51:50 -0700 (PDT) (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.4/8.12.4) with SMTP id g76Jp4Oo001680; Tue, 6 Aug 2002 15:51:04 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Tue, 6 Aug 2002 15:51:03 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: julian@FreeBSD.org Cc: jhb@FreeBSD.org, arch@FreeBSD.org Subject: Problem with credential for initproc Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG A few months ago, I committed some changes to the main tree so that the credential used by init would be divorced from the credential used by proc0 so that operations performed by init in kernel, and once it hit userland, could operate using a different credential. This was required for the MAC code as kernel threads use a special credential for a number policies. I accomplished this by divorcing the initproc->p_ucred from proc0->p_ucred fairly early in create_init() following the call to fork1(). This meant that by the time start_init() was invoked from the now-started init proc, all would be well. Following the seperation, I also invoked mac_create_proc1() to make the initproc-specific cred changes from the version prepared for proc0. At some point with the KSE changes, this broke. I suspect what is going on is the following: - fork1() created initproc from thread0/proc0, but now allocates a struct thread preemptively. FIRST_THREAD_IN_PROC(initproc)->td_ucred became a reference to proc0->p_ucred. - initproc credentials are then divorced, so initproc->p_ucred is now a reference to its own ucred, where the initproc changes are made, but FIRST_THREAD_IN_PROC(initproc)->td_ucred is still pointed at proc0->p_ucred. This meant that until initproc hit userland and the credentials were reset, start_init() runs using a thread that has proc0 creds instead of proc1 creds. It looks like a fix would basically be to sync up the FIRST_THREAD_IN_PROC(initproc) credentails following the divorcing: static void create_init(const void *udata __unused) { struct ucred *newcred, *oldcred; int error; error = fork1(&thread0, RFFDG | RFPROC | RFSTOPPED, &initproc); if (error) panic("cannot fork init: %d\n", error); /* divorce init's credentials from the kernel's */ newcred = crget(); PROC_LOCK(initproc); initproc->p_flag |= P_SYSTEM; oldcred = initproc->p_ucred; crcopy(newcred, oldcred); #ifdef MAC mac_create_proc1(newcred); #endif initproc->p_ucred = newcred; X X Something needs to happen here so that the thread cred is updated X PROC_UNLOCK(initproc); crfree(oldcred); mtx_lock_spin(&sched_lock); initproc->p_sflag |= PS_INMEM; mtx_unlock_spin(&sched_lock); cpu_set_fork_handler(FIRST_THREAD_IN_PROC(initproc), start_init, NULL); } I.e., somewhere around the X's, something needs to happen. This then breaks some events involving MAC in start_init(), since file systems get mounted using the wrong credential, resulting in NFS using the wrong credential, etc. Any suggestions, thoughts, patches? Do we think there might be a related problem involving spare threads elsewhere in the kernel, or is this the only situation where one proc (proc0) changes the credential of another proc (proc1) resulting in them getting out of sync? 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-arch" in the body of the message