Bill, this looks much better. A slightly modified version of this patch will be in 2.3. In 2.4 it is suggested to alter the function call instead of adding the uid variable to the structure. It was slightly more involved so we didn't want to do it in 2.3.

Thanks,
Danny

On 01/19/12 10:19, bill.bro...@bull.com wrote:

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)



Reply via email to