I'm submitting this self-reviewed case for myself. It is closed approved automatic.
Flexible Credentials for Kernel Door Upcalls Release Binding: Patch Stability Level: Consolidation Private Summary ------- This case introduces a new kernel door upcall function which takes a cred_t pointer. This will allow kernel door clients to specify the credentials to be associated with a given upcall, and therefore to control the ucred_t returned by a door server's door_ucred() call. Details ------- PSARC 1998/344 introduced the Sun Private door_ki_upcall() function to allow the kernel to make door calls from kernel space to user space door servers. Door servers obtain the credentials of a caller by issuing door_ucred(), which currently returns a ucred_t based on the credentials of the calling thread. When the kernel does an upcall using door_ki_upcall(), the calling thread (i.e., curthread) can be a user thread executing a system call, a kernel taskq thread, etc. As a result, when a door server issues door_ucred() when servicing a door upcall, the credentials of the caller are not necessarily those associated with the kernel (i.e., "kcred"), and the kernel has no control over what credentials will be used for its upcall. The kernel therefore cannot execute a door upcall with elevated privileges beyond that of the calling thread. This can be problematic if the kernel needs to execute a door operation which requires a privilege which the current thread does not have. A workaround for this problem might be to have the kernel spawn a kernel thread whose purpose is to perform an upcall. This case proposes an easier solution, which is a new door upcall function which allows the caller to specify the credentials associated with the call. int door_ki_upcall_cred(door_handle_t, door_arg_t *, cred_t *); A new function is preferable over modifying the signature and semantics of the existing door_ki_upcall() function, as the door_ki_upcall() function is used by multiple consolidations, and it would be too risky to track down and modify all existing uses. As such, the existing door_ki_upcall() function's semantics remains unchanged, and will simply call through to door_ki_upcall_cred() with a NULL cred_t pointer, indicating that door_ki_upcall_cred() should simply use the current thread's credentials.
