Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 6 Aug 2002 16:24:07 -0700 (PDT)
From:      Julian Elischer <julian@elischer.org>
To:        Robert Watson <rwatson@FreeBSD.org>
Cc:        julian@FreeBSD.org, jhb@FreeBSD.org, arch@FreeBSD.org
Subject:   Re: Problem with credential for initproc
Message-ID:  <Pine.BSF.4.21.0208061616330.65715-100000@InterJet.elischer.org>
In-Reply-To: <Pine.NEB.3.96L.1020806151131.99671F-100000@fledge.watson.org>

next in thread | previous in thread | raw e-mail | index | archive | help


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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0208061616330.65715-100000>