YAMAMOTO Takashi wrote:
>> YAMAMOTO Takashi wrote:
>>
>>> i don't think the veriexec scope is a good idea in general
>>> or an acceptable solution for my specific case.
>> That's a different discussion... basically, Veriexec's pseudo
>> device provides services like loading, unloading, querying,
>> flushing, etc., and may support a few more in the future.
>>
>> The idea is to be able to describe each action specifically
>> rather than a global "can control Veriexec" or "can't", at least
>> in the kauth(9) layer.
>>
>>> can you explain why you want to make it veriexec specific?
>> Why I want to make what Veriexec specific? the scope? because
>> it collects actions relevant only for Veriexec.
>>
>> -e.
> 
> ah, ok.  then i can understand.
> (i thought you meant veriexec-specific vfs/filesystem hooks
> given that you suggested to make nfs call it.)

What I mean, if to put it in more technical terms, is to have the
Veriexec scope with its veriexec_authorize() wrapper, and have
actions like KAUTH_VERIEXEC_LOAD, KAUTH_VERIEXEC_UNLOAD, etc.

If the NFS optimization conflicts only with Veriexec, and it makes sense
to do so, it's possible to add KAUTH_VERIEXEC_NFS_OPTIMIZE (or
whatever).

What do you think?

-e.