Use the logged on User ID from the CSM GUI for authority checking rather than the STC user from the CSM Server

Ah....yes...I would be willing to entertain that. I think we got a request awhile back to make that editable by operators because the operators need to be able to make sure their sessions have the correct paths to start the session. I think we felt at the time that this wasn't dangerous because the port pairing really only gets used during the start command and so replication would already be suspended and any pathing issues in the file would not "disrupt" ongoing replication.

But I can see an argument for wanting to lock that down from operators. In our latest release we now have the ability to minimize exactly what Operators can do. So the infrastructure is there now to do what you're asking, we'd just need to add a new Misc action to that list they can select from.

Can you do me a favor and open a new IDEA for that request?

Ok, I have understood, that this is the current CSM Design.

In my opinion the only thing what should be clarified is, that the Operator role hasn't the possibility to edit the portpairings.csv file. This in not intended on our shop.

Perhaps, if a safcheck to the origin user is not the way you want to go, you can give the customer at the User Administrator Panel an option, that for Operator role a check box is available, where the customer can decide whether he want to give the Operator the edit option for the portpairings.csv or not.

What do you think about this opportunity?

If I'm understanding you correctly then this is in fact expected behavior. As stated previously, the CSM server will not and cannot use CSM users and their permissions when the server edits the file system. This is because the CSM users might not even have access to the file system. If the user has permission in "CSM" (aka admin permission) to update something like the port pairings csv file, then the CSM interface needs to allow this despite the actual user credentials to the file system. So CSM checks the credentials of the user editing the file in the CSM GUI, but then the server edits the file system on the user's behalf. This ensures that if the user is not defined on the file system, but they are an admin in csm, that they can still update the port pairings in the CSM GUI. If you go directly to the filesystem, CSM has no control over that, and thus the filesystem itself checks permissions. If you want more discussion on this please feel free to reach out. Or we may need an Issue open if we need to dig into it deeper.

Reevaluating some of the IDEAs. Can you point me to the Case you opened for this? I don't think the STC user is used when updating the file. When the product is installed it uses the operating system user to validate it can be installed. This user is what needs permissions to the file system and is what the Liberty server uses to make changes to the file system. The user logged into the GUI may or may not even be a user defined to that operating system. In a distributed environment for example, an LDAP user might be logged in but that user can't actually log into the file system. Same situation with CSM running on the HMC. The logged in user on the GUI should allow them to update the file and save it based on their logged in role. But the save to the file system should be the user used to install the product. I'd like to see the case so I can see what error you hit and what support saw.

Hi Developers,
sry that my description was not meaningful for you. I had opened a Case to clarify how CSM should work and why the STC User is used for authority Checking for some functions (e.g. for opening the portpairing.csv file).
The Case was TS004036158 ("For opening the portpairing.csv from the GUI the STC User is used instead of the user who is logged on to the server"). Here are described much more details.
My thought was (no big security leak but I think it is not the best design), that for opening / accessing from the portpairing.csv file the Authority check against the STC / wlp User is used rather the User, who is logged on at the GUI.
At my explanation, I had tried to describe, that our OPERATORs doesn't have write permissions to this file. At USS this is defined as the follows:
Filename Type Permission Audit Ext Fmat Owner Group
portpairings.cs File rwxrwx---+ fff--- --s- ---- USRTPC TPCP#002

And in additional the following ACLs are defined:
ID Read Write eXecute Name Type
5000244 R TPCP#001 GROUP
5000246 R X TPCP#003 GROUP
5000258 R W X TPCP#033 GROUP

If now, e.g. our Operators (they are all connected to TPCP#003) try to save the file at the USS/OMVS itself, this is not working. If they try the same at the GUI, I think this should work, because they can see the Option "DS8000 Port Pairing CSV" and during the save you use the authority from the STC User rather than the authority from the Logged on User. If this is correct I think this is not the best design. If I'm not correct with my assumption please let me know.
Thanks! Daniel

Not understanding this request. The CSM GUI does allow operators to update port pairings but operators cannot update the server properties through the GUI. The logged in user is used to check this. We could potentially remove authority for operators to update port pairings, but I'm not sure that's what you're asking for. Not sure what STC user you're referring to. And CSM still has no control over authority of the file on the operating system. Can you provide more details? Or perhaps we can have a call to discuss further.