>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.
Fair enough. > - 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) No fallback. There's no old pfexec. > Do exec()s block forever until the service is restarted? Do they > block interruptibly? (my guess: yes) If the service isn't registered, you disable all profile shells and pfexec. That, I believe, is a feature. > 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) See above. > - 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 :) The file is still set-uid root; if the kernel cannot figure out which privileges to use, it will fallback to the old set-uid root behaviour. > - Does the kernel cache results from pfexecd? (I'd be surprised if it > didn't!) No, it doesn't. You don't cache things which are cheap to recompute, especially if we're compare this to a full exec. It may save a little but as you point out here, having a cache is expensive so we avoid it. > 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) There's no cache. Casper
