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

[Nicolas Williams]

On Fri, Jul 03, 2009 at 05:43:38AM -0700, Casper Dik wrote:
> The pfexecd is started at boot through SMF as "svc:/system/pfexecd".

 - I thought we weren't supposed to keep the 'd' for daemon in service
   names.

 - What happens of this service is not online, or even, gasp, disabled?

   Is there a fallback on exec()ing the old pfexec, or is that just a
   shim now?  (my guess: no fallback)

   Do exec()s block forever until the service is restarted?  Do they
   block interruptibly?  (my guess: yes)
   
   Is there any way for users to get notification that this service is
   not online when they attempt to use it through pfexec?  (my guess: no)

 - What about exec()ing set-uid programs when the service is
   unavailable?  The kernel will also upcall to this service for those,
   right?  If so, does that mean that if the service is offline then the
   only way to fix it is to login (not su, since it is set-uid!) as a
   user with sufficient privilege and/or authorization?

   Or is there any fallback on the old set-uid behavior in this case?

   (I have no guess about this case :)

 - Does the kernel cache results from pfexecd?  (I'd be surprised if it
   didn't!)

   If so, is there a way to prime this cache as a way to protect against
   problems with the service?  (e.g., pre-load or hardcode entries for
   su(1M)).

   Is this cache flushed on service restart?  On refresh?

 - Does refreshing the service accomplish anything else besides flushing
   any kernel-land cache?  (my guess: no)

Nico
--