Re: [ADSM-L] DSMJ and Authorized User

Thanks Richard for your reply - it's true my first post was incomplete.

Here's what i'm trying to achieve : having a tsm ba client installationwith no root-involved process on a linux x86_64 install

my setup is :
-r-s------- authorized_user authorized_user [...] dsmc
-rwx------ authorized_user authorized_user [...] dsmtca

changing permissions on dsmtca is OK in this case as it is not used tolog in authorized user.

dsm.sys set password generate  and an adhoc passworddir.

This configuration is (I hope) supported as it is described in the BAclient manual.

My backup are run with dsmc schedule launched as authorized_user -everything works fine. ACL are set for authorized_user having readpermissions on everything we have to backup.

I want restore operation to be done with dsmj. Here is where my problemsbegin..

A. The Authentification part

Apparently there's no more documented way to set dsmj forauthorized user. Setting setuid on dsmj doesn't work (splash screenstops at 90%).

       We find the following messages in the dsmerror.log :
       Unable to locate valid trusted communication agent.
       tcpPath is >/opt/tivoli/tsm/client/ba/bin/./dsmtca<. rc is 138
       ANS1501E Trusted agent executino/owner permissions are invalid

I figured out that setting setuid on dsmagent solve this problem- thus we have this final configuration :

       -r-s------- authorized_user authorized_user [...] dsmc
       -rwx------ authorized_user authorized_user [...] dsmtca
       -r-s------ authorized_user authorized_user [...] dsmagent
       -r-x------ authorized_user authorized_user [...] dsmj

B. The Restore/Retrieve part

once we have managed to launch the dsmj, we want now to restorebackup data with our authorized user.Again, we observe that dsmj doesn't support the authorized userconfiguration. In the restore window, dsmj shows us all directory storedbut it hides the files our authorized user doesn't owned. We meet thesame problem in the restore window for archived data.


Thus my question are :

1. Has one manage to set dsmj properly for use by a non authorizeduser ?2. In general, do you consider that this kind of configuration issuitable for backup needs ? Isn't it a good idea to go back to mycustomers and prove them running tsm without accepting root daemon (dsmcschedule) and granting root access (via sudo indeed) to operators issilly, risky and on a maintainability point of view a hell (ACLs seteverywhere, risk of unsupported configuration, upgrade difficulties,mess in the product architecture, etc..). In this case, what is yourapproach and your

arguments to convince your customers.

Thanks for your reply and any ideas on my case :o)

Regards,
Marc REYNES


Richard Sims a écrit :

In making TSM modules Setuid, you are rendering your TSM
configuration unsupported, and risking security problems in  messing
with the product architecture.

Your posting doesn't say what your environment is or exactly what it
is you are trying to accomplish.  If Unix, the sudo command is
available to empower users in limited ways; and the dsmc Set Access
command is the way in TSM to give access to files beyond those owned
by the invoker.

   Richard Sims