What about using sudo?  The authorized users could have access only to the dsm 
executables ( and they would run as user root ).  Root can see all the files.  
We do that here with either the gui or command line.

Bill Evans 
Research Computing Support 
FRED HUTCHINSON CANCER RESEARCH CENTER 

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of 
Marc REYNES
Sent: Friday, March 28, 2008 8:16 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: 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 installation 
with 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 to 
log in authorized user.
dsm.sys set password generate  and an adhoc passworddir.
This configuration is (I hope) supported as it is described in the BA 
client manual.

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

I want restore operation to be done with dsmj. Here is where my problems 
begin..
A. The Authentification part
        Apparently there's no more documented way to set dsmj for 
authorized user. Setting setuid on dsmj doesn't work (splash screen 
stops 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 restore 
backup data with our authorized user.
       Again, we observe that dsmj doesn't support the authorized user 
configuration. In the restore window, dsmj shows us all directory stored 
but it hides the files our authorized user doesn't owned. We meet the 
same 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 authorized 
user ?
    2. In general, do you consider that this kind of configuration is 
suitable for backup needs ? Isn't it a good idea to go back to my 
customers and prove them running tsm without accepting root daemon (dsmc 
schedule) and granting root access (via sudo indeed) to operators is 
silly, risky and on a maintainability point of view a hell (ACLs set 
everywhere, risk of unsupported configuration, upgrade difficulties, 
mess in the product architecture, etc..). In this case, what is your 
approach 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
>