Grant Authority to directory in root directory
Hi All,
How do I grant authority for selected users to access a directory we have built in the root directory containing a transmittal file? I used WRKLNK, but there is no authority access like when you have a folder.
Thanks!
Software/Hardware used:
Software/Hardware used:
ASKED:
October 17, 2012 12:34 PM
Answer Wiki:
Last Wiki Answer Submitted:
Be the first to answer this question.
To see all answers submitted to the Answer Wiki: View Answer History.
I used WRKLNK, but there is no authority access like when you have a folder.
That’s because it uses normal authority rather than the unusual authority needed for “folders”. But what exactly is the problem? Assuming that you have sufficient authority to grant the assignments, WRKLNK will get you straight to the authority for the directory. Why can’t you use it? (You do know that <F23> shows more options?)
Tom
Yes, I know about <F23>. Even with changing public to *RWX and all giving all object authorities it is not working. Went in to IS Navigator and set everything there. I created the file and can drag and drop it. Gave Qsecofr ownership. Anyone other than myself gets a pop up window to sign in to the drive the folder is on and is then denied access. Is there another security level?
You can use Change Authority (CHGAUT) command to grant authority.ex. CHGAUT OBJ(‘/home/fdr1/*.*’) USER(USERID) DTAAUT(*RWX)or CHGAUT OBJ(‘/home/fdr1) USER(USERID) DTAAUT(*RWX)
The authority still didn’t work with the chgaut. Dug around and found that the i-series and network passwords have to be the same for netserver to work, even though the users have the proper authority. Changed one of the user’s passwords to equal their network password. Bingo, right into the directory and file.
Yes, sometime the userID and password can signon but cannot access from network, this time you can use CHGUSRPRF and don’t change any parameter then the UserID will be enabled in network server.
Gave Qsecofr ownership.
You shouldn’t give ownership of any object to any IBM profile, most especially to QSECOFR. But that should be unrelated to the problem.
the i-series and network passwords have to be the same for netserver to work
It’s a little more complicated, but matching profile and password makes things work without additional effort.
The original question asked about a specific technical problem about ‘authority’. It could have helped if the business context was included so we could anticipate where the underlying problem was. In this case, it wasn’t with authority but with authentication.
Are you needing to make this into a more general solution? Or will it be enough to synchronize a few passwords?
Tom