From owner-freebsd-arch Tue Aug 6 16:40:16 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 BB4C437B400; Tue, 6 Aug 2002 16:40:10 -0700 (PDT) Received: from sccrmhc02.attbi.com (sccrmhc02.attbi.com [204.127.202.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id E70CC43E5E; Tue, 6 Aug 2002 16:40:09 -0700 (PDT) (envelope-from julian@elischer.org) Received: from InterJet.elischer.org ([12.232.206.8]) by sccrmhc02.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020806234009.VTSX221.sccrmhc02.attbi.com@InterJet.elischer.org>; Tue, 6 Aug 2002 23:40:09 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id QAA71135; Tue, 6 Aug 2002 16:24:08 -0700 (PDT) Date: Tue, 6 Aug 2002 16:24:07 -0700 (PDT) From: Julian Elischer To: Robert Watson Cc: julian@FreeBSD.org, jhb@FreeBSD.org, arch@FreeBSD.org Subject: Re: Problem with credential for initproc In-Reply-To: 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 On Tue, 6 Aug 2002, Robert Watson wrote: > > > 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 yes, since in normal processes the thread cred is updated on each kernel entry, something extra needs to be done for threads that never go to user space. It's possible that a simple cred_update_thread(FIRST_THREAD_IN_PROC(td)); would be sufficient.. > 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