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 (https://ideas.ibm.com).
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
Post an idea.
Get feedback from the IBM team and other customers to refine your idea.
Follow the idea through the IBM Ideas process.
Specific links you will want to bookmark for future use
Welcome to the IBM Ideas Portal (https://www.ibm.com/ideas) - Use this site to find out additional information and details about the IBM Ideas process and statuses.
IBM Unified Ideas Portal (https://ideas.ibm.com) - Use this site to view all of your ideas, create new ideas for any IBM product, or search for ideas across all of IBM.
ideasibm@us.ibm.com - Use this email to suggest enhancements to the Ideas process or request help from IBM for submitting your Ideas.
We ran into this issue as well, and stayed on TSM 7.1.6 for a long time in hopes that IBM would come up with a solution. However, we've reached the point where we can no longer stay on 7.1.6 and need to upgrade.
To add to this RFE's description:
We use TSM/ISP to backup servers that are shared by many users. Each of these users needs to be able to restore their own files. Users must not have access to other users' files. Some of these users have files scattered in many different paths on the server (a single user's files are not reliably consolidated in a single location such as a home directory).
Prior to TSM 7.1.8, we configured a single dsmcad daemon on each server to backup the entire server. For restores, we allowed any user to run the `dsmc` command as a "non-authorized user", which meant that users could only restore files whose "object owner" on the TSM server matched the "non-authorized user session owner" in the client dsmc process (which was the username of the Linux user that ran the `dsmc` process). This provided a clean and simple solution for our use case.
The IBM documentation related to the TSM 7.1.8 upgrade and removal of the trusted communications agent (TCA/dsmtca) functionality suggests having each user back up their own data using their own "node". This doesn't work well for us for two reasons:
1) It appears that a separate dsmcad daemon is required for each "node", and due to the number of users, running separate dsmcad daemons for every user is not practical on our system.
2) Due to the scattered files for each user, separately managing the backup filespaces and incl-excl lists for each user is not practical.
For us, a better solution is to have "root" back up all of the files under a single "node", then grant individual "user nodes" access to that user's files in the "root node". However, the problem with this is that "set access" only appears to allow granting access based on file path, not based on file ownership. Unfortunately, due to our users' files being scattered across the filesystem, managing access based on file paths is not practical.
It appears to us that there are at least three different ways that IBM could accomodate our use case without re-introducing the TCA or reverting to the old security model:
1) Add support for explicitly granting one node access to another node's files based on file ownership, in addition to or instead of granting access based on filespec (file path). (Eg. by extending the existing "set access" command.)
2) Add support for manually configuring a static "session owner" value on the TSM server for each registered node, then use the old/existing "non-authorized user" logic to prevent a node that has a configured "session owner" value from accessing any files on the TSM server that do not have a matching "object owner".
3) Add support for manually configuring a static "session owner" value in dsm.sys on the TSM client for each configured node, then use the old/existing "non-authorized user" logic to prevent a node that has a configured "session owner" value from accessing any files on the TSM server that do not have a matching "object owner".
Our temporary work-around (to enable us to upgrade TSM/ISP) is to have "root" back up all files under a single "node" for a server, create a separate "node" for each user on each server, then use scripts to find relevant files for each user and automatically generate/update access lists based on file paths to allow each user "node" to access the relevant files in the root "node". However, our scripts are complicated and error-prone, and this scheme doesn't handle some corner cases well (eg. when file ownership changes).
Unfortunately, given the absence of a practical solution for our use case in TSM/ISP, and the fact that IBM appears unlikely to solve this problem any time soon, we are forced to evaluate alternative backup products/solutions.
This request may not be delivered within the release currently under development, but the theme is aligned with the current multi-year strategy. IBM may consider and evaluate any RFE Community feedback for this request through activities such as voting. IBM will update this request in the future.