[torqueusers] stdout, stderr permissions after sys_copy

[Garrick Staples]

On Thu, Dec 15, 2005 at 09:32:42AM -0600, Jeffrey B. Reed alleged:
> Our flow requires that a project group has read access of the output of 
> jobs. Currently these files are copied with the mode 0600.  The issue as I 
> see it is:
> 
> If you are using NFS and have the appropriate $usecp set, sys_copy will use 
> for example:
> 
> /bin/cp -r TORQUE_SPOOL/spool/45.server.m.OU /nfs/location/output-file
> 
> If the destination file does not exist, /bin/cp will use the same mode as 
> the source file.  In this case 0600.  This mode is forced most likely due 
> to the fact that there is no guarantee that the output will be delivered 
> and it would be a security risk to have it set any other way.  I 
> experimented a little and the only solutions I came up with are:
> 
> 1: Ignore security issues
> Discover the submitter's umask and set that umask in start_exec.c
> 
> 2: Use an alternate local copy command
> Discover submitter's umask and use that corresponding mode to call a copy 
> like application that supports modes.  For example: /usr/bin/install 
> --mode=<mode>
> 
> I assume this is not a issue with pbs_rcp or scp, because a proper login 
> occurs on the remote node prior to the copy.

Sounds like a bug with our rcp/scp args!  We need to be using -p too.

I understand that is counter to your requirement, but for the general
case, rcp/scp end up with the wrong perms.

 
> Does anyone have any thoughts on this issue?

I wonder if it would be easier to handle this output within your job
script.  Just redirect the required output to a file and use stageout.

-- 
Garrick Staples, Linux/HPCC Administrator
University of Southern California
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://www.supercluster.org/pipermail/torqueusers/attachments/20051216/0c5e6800/attachment.bin