[drmaa-wg] DRMAA test case for malicous job template input parameter

[Peter Troeger]

I am not sure whether or not this was clarified in today's DRMAA  
conference. I vote for a tracker item, since the spec should clearly  
formulate that both options (error during submission vs. failed state  
of the job) are possible for an invalid job template.

Regards,
Peter.


Am 30.09.2005 um 18:01 schrieb Rajic, Hrabri:

> We are in the gray area I would say.
>
> A test code could reflect that.
>
> DRMAA state diagram has a valuator stage that could reject a job  
> like it
> happened here for Condor.
>
> Sometimes these discrepancies happen due to quality of DRMAA
> implementation, sometimes due to DRM architecture.  This is inevitable
> and we have agreed to have some latitude in the spec to reflect the
> realities in the marketplace.
>
> Regards
>
>     Hrabri
>
>
>> -----Original Message-----
>> From: owner-drmaa-wg at ggf.org [mailto:owner-drmaa-wg at ggf.org] On  
>> Behalf
>>
> Of
>
>> Andreas Haas
>> Sent: Friday, September 30, 2005 10:48 AM
>> To: Peter Troeger
>> Cc: DRMAA Working Group
>> Subject: Re: [drmaa-wg] DRMAA test case for malicous job template  
>> input
>> parameter
>>
>> Hi Peter,
>>
>> On Fri, 30 Sep 2005, Peter Troeger wrote:
>>
>>
>>> Hi,
>>>
>>> the SGE DRMAA test suite has a set of three tests for checking the
>>> behavior in case of incorrect job template settings for the input,
>>> output, or error file path. The following text is the description of
>>> the test case:
>>>
>>>        /* - drmaa_init() is called
>>>           - a job is submitted with input/output/error path
>>> specification
>>>             that must cause the job to fail
>>>           - use drmaa_synchronize() to ensure job was started
>>>           - drmaa_job_ps() must return DRMAA_PS_FAILED
>>>           - drmaa_wait() must report drmaa_wifaborted() -> true
>>>           - then drmaa_exit() is called */
>>>
>>> The funny thing is that the test case expects the (wrong)  
>>> template to
>>> be accepted by drmaa_run_job(), and then expects that the job status
>>> changes to FAILED.
>>>
>>
>> This is due to sentences such as
>>
>>  "If set, and the file can't be read, the job enters the state
>>   DRMAA_PS_FAILED. The attribute name is drmaa_input_path."
>>
>> in DRMAA spec.
>>
>>
>>> The Condor implementation rejects the job template
>>> at submission time with DRMAA_ERRNO_DENIED_BY_DRM, which is in my
>>> opinion the right approach according to the spec.
>>>
>>
>> Possibly with the Condor implementation a "drmaa_transfer_files"
>>
> setting
>
>> "ioe" is in effect by default. This would imply these files are  
>> located
>> at the submit machine. At least this would be an explaination how
>>
> Condor
>
>> can detect at submit time these pathes are invalid.
>>
>> In case of Grid Engine "DRMAA_PS_FAILED" is returned as the
>>
> defectiveness
>
>> of these pathes at the execution machine can't be determined  
>> before the
>> try to start the job.
>>
>> Regards,
>> Andreas
>>
>
>