In-kernel pfexec implementation. [PSARC/2009/377 FastTrack timeout 07/10/2009]

[Casper.Dik at sun.com]

>I'm assuming here that pfexecd is running as root with all privileges ?
>Or is it able to run with a reduced set (for example pfexecd shouldn't I 
>think need most of the current basic privs or file_write from the new 
>set in PSARC/2009/378).  Though it feels to me like it should be running 
>with all privs because other wise a lower privileged process is acting 
>as an authority to hand out privs it doesn't actually have.

Yes, correct.

>Sorry for not bringing this next one up in the prereview but it only 
>just popped into my head.   In the current system pfexec itself will do 
>the nameservice lookup to find the exec_attr entry to use.  If I 
>understand the new system it will be pfexecd doing that, right ?   So 
>this changes things with respect to per user nscd (needed for doing self 
>credential'd lookups) in that user_attr, prof_attr and exec_attr lookups 
>for 'pfexec' won't use the per user nscd ?   Or am I missing something.

Right.  So where's the per-user nscd case?

>In the pre-review we discussed wither or not a TX configuration would 
>have one pfexecd per system (in the global zone) or one per zone.  This 
>would ensure that pfexecd "follows" what happens with nscd which can be 
>one in the global zone or one per zone.  I can't tell from the case 
>material what the decision was on that.

There's apparently one nscd per TX system and it makes sense there's
only one pfexecd in that schema.

Casper