IBM Mainframe Forum

I kind of feel like this is a RACF issue but I can't for the life of me figure out what needs to change so I'm wondering if anyone has seen this before. I can run this Co:Z SFTP script with no problems but I'm a superuser in OMVS. When one of our developers runs the same job, he gets a permission denied error:

CoZBatch[N]: Copyright (C) 2005-2009 Dovetailed Technologies LLC. All rights reserved.
CoZBatch[N]: version 2.1.1 2012-03-16
CoZBatch[I]: executing progname=login-shell="-/bin/sh"
.: FSUM7318 cannot open script "/usr/local/coz/samples/sftp_batch/sftp_connect.sh": EDC5111I Permission denied.
CoZBatch[I]: returning rc=exitcode=0

All the scripts are 755. The directory structure is also 755 all the way back to root. I've tried changing the owner and group specifically to the developer's ID and default group and changing the script permissions to 777 and still get permission denied. I'm wondering if there's some RACF setting we're missing that's causing this issue. The developer ID has an OMVS segment, as does his default group. His default shell is set to /bin/sh which is getting picked up. I'm not sure what else to check.

It may be the Shell script itself 'sftp_connect.sh' is attempting to open a file that the user has not permission to?
Peter

The script calls a custom executable for the product with the same 755 permissions as the script itself. There are no files being transferred with this; it's just a connection test that runs a dir command after connecting and then disconnects.

Harry - did you see any messages in the syslog, RACF access violations? - seen this before, and I don't recall the specifics but I believe if the resource is RACF protected permission bits @ 777 will not work.
maybe someone who knows RACF better will chime in

I didn't think to look there. I found the security violation in the log and the RACF bits didn't match what I saw in OMVS. Then I noticed that the job wasn't executing on the LPAR I thought it was and so all the changes I was making were on the wrong dang system. Arrghh! Thanks, Peter. I'll get the dev to change the jobcard and try it again.

harryseldon wrote:I didn't think to look there. I found the security violation in the log and the RACF bits didn't match what I saw in OMVS. Then I noticed that the job wasn't executing on the LPAR I thought it was and so all the changes I was making were on the wrong dang system. Arrghh! Thanks, Peter. I'll get the dev to change the jobcard and try it again.

Been there done that, I'm still getting use to sharing Unix System Services filesystems, automove, and automount, symbolic links.....all the real neat stuff!
Peter