[HTCondor-users] Preserving output-transferred directory permissions?

[Michael Pelletier <Michael.V.Pelletier@xxxxxxxxxxxx>]

The output transfer process seems to be manipulating or applying a umask to the file permissions on the directories it creates while transferring output files back from scratch space.

 

For example, I submit a job which creates a directory and a subdirectory and sets permissions:

 

transfer_input_files = /bin/mkdir

+PreCmd = "mkdir"

+PreArguments = "-p mode775dir/subdir"

transfer_output_files = mode775dir

 

executable = /bin/chmod

arguments = 775 mode775dir/subdir

transfer_executable = false

should_transfer_files = yes

 

I would expect that the output-transferred “subdir” would have mode 775, with group-write permissions, since that’s what it was set to on the exec node. However, it comes back with 755 permissions.

 

It does appear that there’s some manner of umask at work, because I can set it to 700, 750, etc., and those permissions are preserved, but write permissions for anyone but owner are apparently stripped during the voyage from scratch space to initialdir.

 

Is there a knob for this? They’d like to have output data writable by all members of the project team since it makes it easier for them to manage their output data volume without superuser intervention. We run all our stuff as owner due to our security audit requirements, so there’s no concern connected with a translation from a slot uid to the submitter uid. We just want to be able to set the right file permissions on the output without having to do a DAG.

 

Thanks for any suggestions!

 

                -Michael Pelletier.