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

[Casper.Dik at sun.com]

>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