Bug 675967

Summary:	cannot transfer files back to submit machine when authentication is claimtobe
Product:	Red Hat Enterprise MRG	Reporter:	Martin Kudlej <mkudlej>
Component:	condor	Assignee:	Timothy St. Clair <tstclair>
Status:	CLOSED ERRATA	QA Contact:	Martin Kudlej <mkudlej>
Severity:	low	Docs Contact:
Priority:	low
Version:	1.3	CC:	iboverma, jneedle, matt, tstclair
Target Milestone:	2.0
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	condor-7.6.0-0.7	Doc Type:	Bug Fix
Doc Text:	C: Fails to transfer files back for unknown users who are allowed to submit C: Users fail to obtain a jobs spooled output data F: Schedd will set permission to user nobody R: Condor will now transfer back output files for jobs run from unknown users.	Story Points:	---
Clone Of:		Environment:
Last Closed:	2011-06-23 15:42:12 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	607668, 693778

Description Martin Kudlej 2011-02-08 13:20:44 UTC

Description of problem:
This bug is based on bug 608027. I think if authentication is disabled(claimtobe) it should be possible to do everything(submit job/run job/delete job/tranfer files back/...). Also transfer files from central manager + scheduler when job is done.

Version-Release number of selected component (if applicable):
condor-7.4.5-0.7

How reproducible:
100%

Steps to Reproduce:
1. set up condor central manager and scheduler on linux
2. set up condor execute node on windows
3. disable authentication (claimtobe for client and default authentication variables)
4. submit windows job from windows to linux CM by condor_submit.exe -name <schedd> -spool
5. after job is done try to transfer files back to submit machine condor_transfer_data.exe -name <schedd name> <clusterid>
  
Actual results:
Condor creates job files with permissions which don't allow to transfer files back to submit machine.
For example:
"_stderr -rw------- 1 root   condor"

Expected results:
condor authentication is off(claimtobe) and on both OSes are different user accounts. It is possible to submit jobs/transfer files back/run job/...

Comment 1 Timothy St. Clair 2011-02-17 21:23:30 UTC

NOTE: This needs validation in a non-kerber-ized environment

Comment 2 Timothy St. Clair 2011-03-22 19:48:37 UTC

blocks on: https://condor-wiki.cs.wisc.edu/index.cgi/tktview?tn=1985

Comment 3 Timothy St. Clair 2011-03-29 17:45:52 UTC

With fix in https://condor-wiki.cs.wisc.edu/index.cgi/tktview?tn=1985 you can remote submit with a known user.  However, there is a new failure when submitting as a unknown user: https://condor-wiki.cs.wisc.edu/index.cgi/tktview?tn=2004.  

Both of these issues were introduced in the 7.6 series.

Comment 6 Timothy St. Clair 2011-04-11 21:58:56 UTC

Fixed upstream.  

There has been a additional config variable added, set: 

SHADOW_RUN_UNKNOWN_USER_JOBS = TRUE 

on your submit node in order to enable this functionality, it is FALSE by default.

Comment 8 Timothy St. Clair 2011-05-04 16:44:35 UTC

    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
C: Fails to transfer files back for unknown users who are allowed to submit
C: Users fail to obtain a jobs spooled output data
F: Schedd will set permission to user nobody
R: Condor will now transfer back output files for jobs run from unknown users.

Comment 9 Martin Kudlej 2011-06-07 14:00:24 UTC

Tested on all supported Windows versions with condor-win-7.6.1-0.10 and it works. -->VERIFIED

Comment 11 errata-xmlrpc 2011-06-23 15:42:12 UTC

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHEA-2011-0889.html