IFS Security

[edfishel@us.ibm.com]

Doug, There are two unique things you need to be aware of: 1. The *GRPPRF parameter is ignored for all file systems except QSYS.LIB. In cases where the parameter is ignored, the user retains ownership of the object. 2. Adopted authority is not used by the integrated file systems, including the ?root? (/), QOpenSys, QDLS, and user-defined file systems. You did not say if you are using CHGAUT to give *RWX authority to public or to the group profile. I assume that it is the group. It is also not clear why the second user needs to run the CL program. It seems to me that the RPG program should call the CL program after creating the stream file. No one else should ever call it. The CL program should use CHGOWN with RVKOLDAUT(*YES) to change the file to be owned by the group profile. Then from this point all the members of the group should be allowed to do whatever they wish to the file. Note: If they need to delete the file then they will need at least *WX authority to the parent directory of the file. Perhaps the group should also own this directory. Depending on your authority design you may also need to use CHGAUT within the CL program to give the group profile *RWX authority. This may not be everything you need to do but I hope it helps. Ed Fishel

[Guest.Visitor]

IFS Security

Ed, Thank you for your reply. I am using CHGAUT to grant authority to the group profile, not *PUBLIC. What you outline is pretty much what I am doing, so that is good, in my view. I have one question, though. When I do the CHGOWN, sometimes I get an error message ("Access problem"). The message is very generic, and not too helpful. I read some IBM documentation that says you will get this message if the owner you are trying to change "TO" is already the owner of the object. So my question would be twofold: One, is this the only meaning of the ACCESS PROBLEM error message (in which case I could monitor for it)? Second, is there a command similar to RTVOBJD that I can use to get the OWNER of an IFS object? If so, then I would use that command and only change the owner if the owner was not the owner that I needed for the object. Thank you again! Doug

[edfishel@us.ibm.com]

IFS Security

Doug, Without a message ID, I can only guess what "Access Problem" means. I know of no commands that allow you to retrieve the owner of a stream file. The Retrieve Users Authorized to an Object (QSYRTVUA) API and the Qp0lGetAttr()--Get Attributes API both will give you the owner of the stream file. When the stream file is created it will be owned by the current user of the job. The only time that would be the group profile that you are trying to change the ownership to would be when the job/thread was running as (swapped to) that group profile. Perhaps you could use RTVJOBA to retrieve the current user of the job as a way to determine who owns the stream file you just created. If you are creating the stream file and letting its public authority default to be the same as its parent directory then that may cause the owner of the stream file to have less than all authority to it. In other words, the owner may not have authority to change the owner of their own object. If that is the case then you would first need to grant them the necessary authority before changing the owner. Ed Fishel

[Guest.Visitor]

IFS Security

Hello Doug, We had similar problems, We solved them by using a Primary Group Profile on the folder. When you issue the command CHGPGP you can specify the authorities granted to the Group Profile. OS/400 (i5/OS, we're on V5R3) will grant authority to files placed in this folder.If your users have this Group Profile as a group profile all should work. Success Paul Holst

[Guest.Visitor]

IFS Security

I have question regarding the IFS: I want to be able to have a CL create an output file and place it on the IFS using CPYTOIMPF. Once the file is on the IFS, it must be very secure. I have a group profile defined. There are three or four users that have that group profile listed as a profile in their SUPGRPPRF parameter. All of those user ids have the OWNER parameter set as *GRPPRF. We are running V5R2. I want to be able to allow any of the users who belong to the special profile to be able to access the file in the IFS and read/write/delete it. No one else should have authority to this file and folder on the IFS (nor on the iSeries). What I have done is: compile the CL that runs this process with the USRPRF(*OWNER) and AUT(*EXCLUDE) parameters on the CRTCLPGM command. I then change the owner of the CLP to the group profile I had defined above. After the RPG program runs, it copies the iSeries DB2 file to the IFS using the CPYTOIMPF command. The MBROPT(*REPLACE) parameter option is used. After the CPYTOIMPF command completes, the CL runs the CHGAUT command, and changes the authority of the new IFS object to be *RWX for the new file created. That works fine. However, when I run the CL under one user who creates the file, and then run the CL again under a different user (both of which are in the group profile), I get an access error when the CHGAUT command executes under the second user. I get CPFA0B1 when the CHGAUT command attempts to run. My questions are: 1) Can I do what I am looking to do? 2) Should I be using the CHGOWN command on the newly created IFS object rather than or in addition to, CHGAUT? 3) Has anyone else had similar issues with authority on the IFS? Any help would be appreciated! Thank you, Doug

[Guest.Visitor]

IFS Security

I'm far from an expert on IFS security, but I needed to do EXACTLY what you want to do and was able to make it work. Several things to check out and research is that in the IFS there are the data authorities *RWX which get all the attention but there are also *OBJ authorities that must be set. These as are required to work with permissions and other object management and existence like CHGAUT. Three things I would check: 1) does the user profile have at least *X data rights to each directory leading to and including the directory that the IFS object resides in, they probably need to have object rights as well, but that I have not confirmed, 2) verify that the users of the object and the containing directory have *object rights and finally 3) verify that the profile under which the program that runs under has *RWX and object rights. Case in point, we were running a CL program set user(*owner) where the owner was QSECOFR and still received CPF0AB1 when USERA ran the aprogram. When we gave USERA *RWX and object(*all) rights it worked fine. If you do all that and then dance around the CPU shaking a chicken's foot I think you'll be able to make it work.