NOw I haven't played with the web interface much (except the admin)
     but in a general unix environment if you have paths set up where an
     individual user id may run "dsmc" you will find that :
     1) to "backup" a file you must be the owner of the file (or that
     special owner of all "root".  This is mainly due to the fact that with
     backups (incremental or selective) it rolls off older data (due to the
     versions data exists parameter) and it doesn't allow anybody else to
     do anything to another's files that would cause some versions to be
     expired/deleted
     2) to "archive" a file you must have "read" access to the file, then
     the person performing the "archive" is the owner of that archive.
     3) YES, the UID is used to determine the "owner" of the back version
     of the file.  Try a "query backup" of a file you don't own!  It will
     tell you "no data exists" (unless, naturally, the owner of the file
     has performed a "set access" for the other userid on that system or
     another system, OR you are "root")
     4) I think V2 keys off the "UID" but I think V3 uses both/either UID
     or userid... across systems our userid's keep consistent UID's
     I know if "root" on another box retrieves another box's backup of a
     UID that isn't assigned to a userid on the box you are retrieving it
     to, the owner just shows up as the numeric UID... same for the group.

     From what I have seen about the web interface, since you define user
     id's and passwords to be able to use it, it seems to be designed for
     use by a central "help desk" environment, staffed by "trusted
     employees" to perform restore requests for the general user public.
     It is up to the help desk to validate security issues.

     Now what you could do is have a box with a community wide NFS mounted
     "shared" filespace (say /scratch on server "restore") have every other
     client box nfs mount this locally, then on each client perform a
     set access backup /home/*/* restore helpdsk*
     set access archive /home/*/* restore helpdsk*
     from the source client(s) as "root" then when the userid "helpdsk1"
     logged onto node "restore" went to request, say
        "restore -fromnode=engrsrv1 -fromowner=joebob /home/joebob/bin/x
         /scratch/home.joebob.bin.x"
     (note the substution of "." for directory level changes)
     adsm would check if the userid "helpdsk1" on node "restore" (which it
     does) and would restore it to the directory "/scratch/" under the file
     name "home.joebob.bin.x" then the help desk would notify that the file
     was restored, where it was restored, and what it is/was called (then
     give the user 24 hours to determine if it is the correct file and copy
     it somewhere (back to its origional location before some automatic job
     runs that clears the directory "/scratch/" on their shared disk on
     server "restore")

     I believe this would work...

     later,
          Dwight
     (sorry, don't have current time to double check this...)



______________________________ Reply Separator _________________________________
Subject: How to limit restore to a subset of a node's files? (UNIX)
Author:  eric.lewis at unix,mime/DD.RFC-822=eric.lewis AT CCMAIL.ADP.WISC DOT 
EDU
Date:    3/18/99 2:39 PM


     Hi:

     I think I know how to permit multiple individuals to backup and
     restore only their own files on common shared server.

     I believe the brute force way would be to define a node name per
     indidividual customer/file set with an individual directory and
     software instance per node, then use UNIX access control to limit the
     directories and files that each particular instance of the backup
     client could see . . . and use excludes in each node's directory to
     assure there are not access control failures during backup.  I gather
     that each such "node" would need an instance of the scheduler to be
     loaded and connected to the server.

     The advent of the Web Client stirred hopes that somehow restores could
     be limited/linked to the individual who is doing the restore.  I
     believe this is not the case though I see that ADSM does carry the
     UNIX "owner" attribute in the node's directory database.  Certainly
     this information would be needed for such a feature.

     Would anyone comment on how accurately I describe the
     situation/solution?  Thanks for your help.

     Eric Lewis UW-Madison