[torqueusers] stdout, stderr permissions after sys_copy
garrick at usc.edu
Fri Dec 16 19:52:09 MST 2005
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
> 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
Size: 189 bytes
Desc: not available
Url : http://www.supercluster.org/pipermail/torqueusers/attachments/20051216/0c5e6800/attachment.bin
More information about the torqueusers