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" <lipa...@llnl.gov> Sent by: owner-slurm-...@lists.llnl.gov 01/16/2012 04:50 PM Please respond to slurm-dev@lists.llnl.gov To "slurm-dev@lists.llnl.gov" <slurm-dev@lists.llnl.gov>, "bill.bro...@bull.com" <bill.bro...@bull.com> cc Subject RE: [slurm-dev] sprio doesn't honor PrivateData > -----Original Message----- > From: owner-slurm-...@lists.llnl.gov [mailto:owner-slurm- > d...@lists.llnl.gov] On Behalf Of Mark A. Grondona > Sent: Monday, January 16, 2012 7:57 AM > To: bill.bro...@bull.com; slurm-dev@lists.llnl.gov > Subject: Re: [slurm-dev] sprio doesn't honor PrivateData > > On Mon, 16 Jan 2012 08:28:19 -0700, bill.bro...@bull.com 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
