Re: PASSWORDACCESS GENERATE

I'm not sure what you mean by "implicit" vs. "explicit". Whereas I can see how
the issues of where to place the NODENAME option can cause confusion, such
placement should not automatically (or implicitly) grant root-level rights to
the data, unless you've also given them the ADSM password.

By the way, the confusion over where NODENAME goes is being addressed in V3.
NODENAME will still go in dsm.sys, but for dsm.opt it is being replaced with
VIRTUALNODENAME.

Andy Raibeck
ADSM Level 2 Support

        ADSM-L AT VM.MARIST DOT EDU
        10-22-97 06:09 PM
Please respond to ADSM-L AT VM.MARIST DOT EDU @ internet

To: ADSM-L AT VM.MARIST DOT EDU @ internet
cc:
Subject: Re: PASSWORDACCESS GENERATE - problem

>
> This is not a limitation. When you put NODENAME in a UNIX dsm.opt file (or if
> you specify it on the command line, i.e. "dsmc -nodename=3Dwhatever"), you are
> indicating that you are a "virtual root user". You should be prompted for the
> password. If you know the password, then you will have access to all of  that
> node's versions. This is documented in "Using the UNIX Backup-Archive Clients"
> in the reference section describing the NODENAME option.
>
> If NODENAME is set in dsm.sys, you won't get a password prompt and you won't
> a virtual root user. This is a way of over-riding the default nodename, which
> is the machine name. If NODENAME is in dsm.opt, then you should be getting a
> password prompt.
>
> Andy Raibeck
> ADSM Level 2 Support

Actually, I came across this very type of thing recently, in trying to set
up a virtual node for archival and retrieval.  A huge pain in the neck.

My only comment on this is this:   Despite the fact that the behaviour is
documented, implicit rights based on WHERE apparently unrelated options
are set are insecure, unnatural, error prone, and difficult to trace.

I've seen some poor design decisions in ADSM that were merely inconvenient,
but this behaviour is a flat design *flaw*.  Security should mandate that
only the minimum rights (i.e. user-level stuff) be granted implicitly, and
that any rights in excess of that (i.e. root-level stuff) be requested and
authenticated EXPLICITLY.  And, the protocol for granting such rights should
be sufficiently robust as to prevent accidental granting of rights or acci-
dental denial of service (such as would happen if you placed the NODENAME
in the wrong file).

It would be nice to see a command line flag that enables/disables access
as a virtual-root-user, with an explicit password being required.

Mark

--
============== See me at http://www.Tulane.============== See me at 
http://www.Tulane.EDU/~mjc ======================
Mark Justin Cecil    |  Tulane University    | mjc AT mailhost.tcs.tulane DOT 
edu
Systems Programmer   |   Computing Services  |     cecil AT eecs.tulane DOT edu
(504) 865-5631 x 2535|    New Orleans, LA    |  http://www.Tulane.edu/~mjc