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