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
