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

[Darren J Moffat]

Casper.Dik at Sun.COM wrote:
> 
>> 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?

PSARC 2005/133 covers the introduction of per-user nscd.

It is enabled by setting 'enable-per-user-lookup'.

>> 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.

txzonemgr can be used to change that between one per system and one per 
zone and the method script for svc:/system/name-service-cache sets it up.

-- 
Darren J Moffat