Manage Learn to apply best practices and optimize your operations.

Give a user temporary *RWX authority

Since the root system in the IFS does not support adopted authority, what's the best way to give a user temporary *RWX authority to a MS Word document that normally has *RX authority for all users (*PUBLIC) and object authorities of *NONE?

What I've done is have an interactive RPG program submit a job to batch to change the MS Word document authorities for the interactive user. The submitted job user has *ALL authorities to the IFS PC document.

The interactive job waits until the submitted jobs completes. I register a cancel handler to reset the authorities if the interactive job is cancelled. Seems like there must be a better way!

You're right, there is a better way. As you have discovered, adopted authority is not honored when trying to access objects in the IFS. So you might want to try changing the process to run under a user that does have the required authorities - in this case *RWX. To get the process to run with someone else's authority there are three sets of APIs that you can use - swap profile, profile token and UID / GID.

* Profile swap APIs have been around for quite awhile. These are the APIs that the servers (like FTP and telnet) use to get the job to run as the requesting user rather than the user the server started under. When a process' profile is swapped, all security attributes are swapped in including the new user's special authorities, limited capability attributes and group profile(s). The use of the profile handle that has to be generated before the profile is actually swapped is limited to the process that generated it.

* Profile token APIs were new in V4R5. They have the same effect as the profile swap APIs except the token can be passed between jobs and can be generated as one-time use, multi-use or to time-out and become invalid for use.

* The uid and gid APIs also were introduced in V4R5. Unlike what happens with the profile swap or profile token APIs, the uid and gid APIs only swap in either the user, as in the case of the uid APIs, or the group, as in the case of the gid APIs. (The uid is the numeric representation of the user, rather than using the user profile name. The gid is the numeric representation of the group profile.)

Prior to accessing the document you could use one of the GID APIs to set the user that has *RWX as the accessing user's first group profile. The appealing part of this solution is that this group is in effect for that thread ONLY. In other words, if the user tries to access the document via FTP or ODBC, they will only have *RX authority, not *RWX.

Hope this helps.


The Best Web Links: tips, tutorials and more.

Search400's targeted search engine: Get relevant information on security.

Ask your systems management questions--or help out your peers by answering them--in our live discussion forums.

Dig Deeper on iSeries system and application security

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.