I had written:
> >A possible pitfall is that the use of the pw=generate meachnism changes
> >the semantics:
> >
> >- If you do specify the password, ADSM treats you as root user, i.e. it
> > allows you to work for all Unix users, loading their files up and down
> > (of course only those files Unix allows you to read or write). But you
> > can reload another user's file into your own directory.
> >
> >- If you enter the ADSM client via a generated password, ADSM allows you
> > to operate only on the files you own. This is reasonable because you do
> > not want that user A can reload user B's files into user A's directory.
> > For regular scheduled backups, this is probably not what you want.
> >
> >This feature is not documented.
> >
> >For regular backups of the entire file system, you have to live with the
> >passwords revealed as described. As a consequence, you should make sure
> >that the backup is performed on a machine where no normal user has access,
> >otherwise all backed up files are open to the public (for reading only).
On Wed, 13 Sep 1995, Paul Zarnowski <psz1 AT cornell DOT edu> answered:
> I don't see why you don't just use the passwordaccess=generate option, and
> run the regularly scheduled backups as root. You said "For regular
> scheduled backups, this is probably not what you want", but I don't see
> why not. Unless it is because you do not want to run the regular scheduled
> backups from the root userid. Is this the case?
The background of my remark is that we discovered by mere chance that a
user who came in by explicit password has (against ADSM, not against Unix)
the right to act on behalf of any other user. This alarmed us very much.
We then found out by trial and error that this is not so when the access
was via a generated password. The conclusion was that the decisive
difference in rights is not whether one is root but how one comes in to
ADSM.
Paul's remark questions this conclusion. If I understand him correctly, I
should have worded my two paragraphs as follows:
If you do specify the password or if you are indeed root on your system,
ADSM treats you as root user, i.e. it allows you to work for all Unix
users, loading their files up and down (of course only those files Unix
allows you to read or write).
If you enter the ADSM client via a generated password but you are not
root on your system, ADSM allows you to operate only on the files you own.
If this is so, you can set up scheduled backups without displaying your
ADSM password.
As I wrote, these rules are undocumented, and it takes a while to find
them out. We have not conducted another experimentation series because we
think our present configuration is satisfactory in this respect.
The rules stated above have not been verified by experiment, and I cannot
do it because ADSM has been down here for a week and will remain so for
some time. Hence, before applying these rules, one should do some more
testing. Much better would be, if ADSM development could document their
access rules.
Another caveat in this area: although there is a client for AIX that
alleges to support AFS, AFS access control has no effect for the backup
copies of these files. This may cause security problems in some end cases
but usually only prevents allowed access instead of granting unallowed
access. The main problem with AFS arises if a file's owner in the Unix
sense is different from the file's owner in the AFS sense (either the AFS
volume owner or a person who has got all rights in that directory).
Regards,
Helmut Richter
============================================================================
Dr. Helmut Richter
Leibniz-Rechenzentrum X.400: S=Richter;OU=lrz;P=lrz-muenchen;A=d400;C=de
Barer Str. 21 RFC822: Helmut.Richter AT lrz-muenchen DOT de
D-80333 Muenchen Tel.: ++49-89-2105-8785
Germany Fax: ++49-89-2809460
============================================================================
|
