|
|
|
|
|
|
| Author |
Message |
Robert Watson *nix forums Guru Wannabe
Joined: 22 Mar 2002
Posts: 218
|
Posted: Tue Aug 06, 2002 7:51 pm Post subject:
Problem with credential for initproc
|
|
|
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 |
|
| Back to top |
|
 |
Julian Elischer *nix forums Guru Wannabe
Joined: 20 Mar 2002
Posts: 279
|
Posted: Tue Aug 06, 2002 11:24 pm Post subject:
Re: Problem with credential for initproc
|
|
|
On Tue, 6 Aug 2002, Robert Watson wrote:
| Quote: |
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..
| Quote: | 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 |
|
| Back to top |
|
 |
Robert Watson *nix forums Guru Wannabe
Joined: 22 Mar 2002
Posts: 218
|
Posted: Wed Aug 07, 2002 5:43 pm Post subject:
Re: Problem with credential for initproc
|
|
|
On Tue, 6 Aug 2002, Julian Elischer wrote:
| Quote: | 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..
|
Adding the cred_update_thread() call to init_main.c following the
credential divorcing code appears to have the right effect: code in
start_init() now uses the correct credential prior to the userland process
launching, so the root file system is mounted using the right label, and
nfs sockets are created and labeled properly. I'll merge the change to
the main tree.
I notice that cred_update_thread() currently grabs Giant -- is this
something that can go away at some point? The proc lock is clearly
necessary, but my initial reading also suggests it should be
sufficient...?
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 |
|
| Back to top |
|
 |
Julian Elischer *nix forums Guru Wannabe
Joined: 20 Mar 2002
Posts: 279
|
Posted: Wed Aug 07, 2002 9:21 pm Post subject:
Re: Problem with credential for initproc
|
|
|
On Wed, 7 Aug 2002, Robert Watson wrote:
| Quote: |
On Tue, 6 Aug 2002, Julian Elischer wrote:
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..
Adding the cred_update_thread() call to init_main.c following the
credential divorcing code appears to have the right effect: code in
start_init() now uses the correct credential prior to the userland process
launching, so the root file system is mounted using the right label, and
nfs sockets are created and labeled properly. I'll merge the change to
the main tree.
I notice that cred_update_thread() currently grabs Giant -- is this
something that can go away at some point? The proc lock is clearly
necessary, but my initial reading also suggests it should be
sufficient...?
|
I don't know
jhb was fiddling with it..
I don't know if it is needed or not..
| Quote: |
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 |
|
| Back to top |
|
 |
Google
|
|
| Back to top |
|
 |
|
|
The time now is Fri Jan 09, 2009 2:55 am | All times are GMT
|
|
Promotional Web Design | Bankruptcy | Debt Consolidation | Great deals at Champion Achiever | Buy WoW Gold
|
|
Copyright © 2004-2005 DeniX Solutions SRL
|
|
|
|
Other DeniX Solutions sites:
Unix/Linux blog |
electronics forum |
medicine forum |
science forum |
|
|
Privacy Policy
|
Powered by phpBB © 2001, 2005 phpBB Group
|
|