Attached is a new version of the patch in which I have made the changes recommended by Don and Mark. Thank you for your inputs. I am all for keeping things simple and consistent. Best Regards, Bill
"Lipari, Don" <[email protected]> Sent by: [email protected] 01/16/2012 04:50 PM Please respond to [email protected] To "[email protected]" <[email protected]>, "[email protected]" <[email protected]> cc Subject RE: [slurm-dev] sprio doesn't honor PrivateData > -----Original Message----- > From: [email protected] [mailto:owner-slurm- > [email protected]] On Behalf Of Mark A. Grondona > Sent: Monday, January 16, 2012 7:57 AM > To: [email protected]; [email protected] > Subject: Re: [slurm-dev] sprio doesn't honor PrivateData > > On Mon, 16 Jan 2012 08:28:19 -0700, [email protected] wrote: > > A user pointed out that sprio doesn't honor the slurm.conf > PrivateData > > option. The attached patch, built using 2.3.2, addresses that > issue. > > Should the uid be filled in from the auth credential, instead of > the client? Or is the uid compared against the auth (munge) credential > at some point? (sorry, I didn't check) > > mark The customary practice is for the client to not send the invoking user's uid. Instead, the control daemon invokes uid_t uid = g_slurm_auth_get_uid(msg->auth_cred, NULL); to determine the uid of the caller. This currently happens in _slurm_rpc_get_priority_factors(). The patch could be simplified to just set the new priority_factors_request_msg_t uid member in _slurm_rpc_get_priority_factors() before calling priority_p_get_priority_factors_list(). The packing/unpacking additions would technically not be required either. Don > > > Best Regards, > > Bill > > > > > Non-text part: text/html > Attachment: sprio.patch (application/octet-stream)
sprio.patch
Description: Binary data
