On Wed, 3 Jun 2009, Wesley Shields wrote: Hi, >>>>... > [ The panic message and backtrace from ddb is at > http://people.freebsd.org/~wxs/crash.txt ] > ... > cred->cr_prison is null? It is my understanding that when not jailed > cred->cr_prison should be &prison0 with the new hierarchical jails. The > fact that it is null is causing prison_priv_check to enter the switch > statement, leading to the crash. > > I'm not sure why cred->cr_prison is null in this case. The question here is not if cred->cr_prison can be null but where is the cred coming from? If you look at init_main.c around lines 440 - 457 you'll find prison0 being further initialized (cpuset) and p_ucred->cr_prison being set to &prsion0. And a bit further down in l470 td_ucred is initialized from that. cr_prison should thus always be setup. What you are looking at above looks like a crget() with only cr_ngroups updated. [removing a lot more text as I was going on debugging in a very small window] I would start looking at svc_getcred() and blame at least the AUTH_UNIX case; end of rpc/svc_auth.c. This looks like a big NO-NO. I am pretty sure I'd also want to audit svc_rpc_gss(), just in case. /bz -- Bjoern A. Zeeb The greatest risk is not taking one.Received on Wed Jun 03 2009 - 18:01:09 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:49 UTC