>   Look at the ADSM command line Set Access command or the GUI Utility
> Set Authorization.  I think they are what you need.

Not quite. That method works well enough when each user has an
assigned workstation, but fails when there is a pool of
workstations and the users move around a lot, such as in a lab
situation with many (potentially thousands) of users and an
arbitrary number of machines using a central file server. The
idea is to run ADSM backups from where the disks are (ie, on
the server), but allow users to restore files from any of the
client workstations. Granting authorizations for all users and
all workstation combinations is a n**2 problem, and is
error-prone at best.

A simple solution would be to make the Unix clients consistent
with the other clients and code the HOSTNAME parameter in dsm.sys
instead of relying on what the 'hostname' command returns. This
would easily permit the scenario described above, and also fix
the problem with having 'hostname' return the host name (not the
FQDN) in an environment where there may be machines with the same
host name, but differing domain names (eg. foo.is.rice.edu vs
foo.cs.rice.edu -- both are legal, but if both configure their
hosts to use 'foo' as the hostname, ADSM gets very confused).

>   To grant the user access, on the file server client, from the ID
> that did the backup, you'd need to create two access rules.
> On the GUI screen, they would look like this:
>
>   Type   Node         User            Path
> ------------------------------------------------------------
> Backup   Usernode     User1           /homedir/*
> Backup   Usernode     User1           /homedir/*/*

While this works in theory, it is impractical when you have 5-6
thousand users and 200-300 machines. It consumes a excessive
amount of database storage, and is a major consistency problem.