Re: IPSEC (both stacks) slight adaptation to kauth(9)

[christos%astron.com@localhost (Christos Zoulas)]

In article <4B3C2C8E.7010706%NetBSD.org@localhost>, Elad Efrat  
<elad%NetBSD.org@localhost> wrote:
>-=-=-=-=-=-
>
>Hi,
>
>Our IPSEC stacks both have a SP PCB structure with a 'priv' field,
>indicating whether this SP is "privileged" or not. The SP, which is
>attached to a socket, gets this value set by by querying the socket's
>uid, from the uidinfo field in the socket. In turn, the 'priv' field
>is used in authorization. (If the uid is zero, it's privileged, and
>vice versa.)
>
>This of course doesn't fit with our transition to centralized
>authorization and support for changing security policy (e.g. a MAC
>policy that changed will not have any effect if the authorization is
>done internally against a cached decision.)
>
>The attached diff addresses this last abuse for uidinfo for
>authorization by doing the following:
>
>   1. Reorganize the switch statements so they are easier to understand.
>      They differ only slightly, and as the networking stacks have enough
>      duplicated code as it is, this is a step in the right direction if
>      we are to eventually clean them up.
>
>   2. Remove the 'priv' field of the SP PCB structures from both IPSEC
>      and FAST_IPSEC. Isolate it to the relevant context, and retrieve
>      its value in runtime and don't cache it.
>
>   3. Replace uid comparison for privileged/unprivileged distinction with
>      kauth(9) calls. For now, these are done on the generic scope as I
>      have other changes in the pipe; once committed, these will be
>      changed to use the network scope.
>
>Please review. :)
>
>Thanks,
>
>-e.
>
>
>-                      break;
>+      unpriv = kauth_authorize_generic(so->so_cred, KAUTH_GENERIC_ISSUSER, 
>NULL);

...

>+              unpriv = kauth_authorize_generic(so->so_cred,
>+                  KAUTH_GENERIC_ISSUSER, NULL);

Why two calls to kauth_authorize_generic?

christos