niXforums Forum Index
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   PreferencesPreferences   Log in to check your private messagesLog in to check your private messages   Log inLog in 
·  nixdoc.net ·  man pages ·  Linux HOWTOs ·  FreeBSD Tips ·  Forums
navigation Forum index » *nix » BSD » FreeBSD » mail-lists » Architecture
Problem with credential for initproc
Post new topic   Reply to topic Page 1 of 1 [4 Posts] View previous topic :: View next topic
Author Message
Robert Watson
*nix forums Guru Wannabe


Joined: 22 Mar 2002
Posts: 218

PostPosted: Tue Aug 06, 2002 7:51 pm    Post subject: Problem with credential for initproc Reply with quote

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

PostPosted: Tue Aug 06, 2002 11:24 pm    Post subject: Re: Problem with credential for initproc Reply with quote

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

PostPosted: Wed Aug 07, 2002 5:43 pm    Post subject: Re: Problem with credential for initproc Reply with quote

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

PostPosted: Wed Aug 07, 2002 9:21 pm    Post subject: Re: Problem with credential for initproc Reply with quote

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
Display posts from previous:   
Post new topic   Reply to topic Page 1 of 1 [4 Posts] View previous topic :: View next topic
The time now is Fri Jan 09, 2009 2:55 am | All times are GMT
navigation Forum index » *nix » BSD » FreeBSD » mail-lists » Architecture
Jump to:  

Similar Topics
Topic Author Forum Replies Last Post
No new posts Unknown in header problem -SOLVED- Light Speed Postfix 0 Thu Jul 03, 2008 10:40 am
No new posts problem with sending mail nuxia Postfix 0 Mon Apr 21, 2008 3:58 am
No new posts Postfix 2.3.8 Virtual problem Blotto Postfix 0 Fri Apr 04, 2008 6:11 am
No new posts Postfix sending problem for local domain remote email monkey_magix Postfix 0 Mon Sep 10, 2007 10:17 am
No new posts bounce problem murkis Postfix 0 Sun Oct 08, 2006 3:45 pm

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
[ Time: 0.2343s ][ Queries: 16 (0.1352s) ][ GZIP on - Debug on ]