Skip to Main Content
IBM System Storage Ideas Portal

This portal is to open public enhancement requests against IBM System Storage products. To view all of your ideas submitted to IBM, create and manage groups of Ideas, or create an idea explicitly set to be either visible by all (public) or visible only to you and IBM (private), use the IBM Unified Ideas Portal (

Shape the future of IBM!

We invite you to shape the future of IBM, including product roadmaps, by submitting ideas that matter to you the most. Here's how it works:

Search existing ideas

Start by searching and reviewing ideas and requests to enhance a product or service. Take a look at ideas others have posted, and add a comment, vote, or subscribe to updates on them if they matter to you. If you can't find what you are looking for,

Post your ideas
  1. Post an idea.

  2. Get feedback from the IBM team and other customers to refine your idea.

  3. Follow the idea through the IBM Ideas process.

Specific links you will want to bookmark for future use

Welcome to the IBM Ideas Portal ( - Use this site to find out additional information and details about the IBM Ideas process and statuses.

IBM Unified Ideas Portal ( - Use this site to view all of your ideas, create new ideas for any IBM product, or search for ideas across all of IBM. - Use this email to suggest enhancements to the Ideas process or request help from IBM for submitting your Ideas.

Status Not under consideration
Created by Guest
Created on Aug 25, 2020

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

If an update is made from the (e.g.) portpairing.csv from the CSM Web Interface (Version 6.2.8) there is no security checking whether if this user has the necessary permission to update this file. The update will be with the STC User from the CSM Server performed. This is from security perspective not really that what I can expect what it should do.

Idea priority Medium
  • Guest
    Aug 25, 2023
    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?
  • Guest
    Aug 25, 2023

    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?

  • Guest
    Aug 24, 2023
    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.
  • Guest
    Jul 13, 2023
    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.
  • Guest
    Sep 16, 2020

    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

  • Guest
    Sep 15, 2020

    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.