[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: snmpconf General Functional Questions

I think I understand what you are asking for.  If there were a way without 
excessive violence to the system to cause the "user" to get an error if he 
tried to change something that was under policy control without first 
removing it, I would at least be sympathetic to the two step process.

But, if we make it a two step process without such coupling, what happens 
is that the "user" makes a change, gets no error, and comes back later and 
discovers it is gone.  The "user" involved may well not be familiar with 
the policy mechanisms (someone else takes care of that).  He needs to make 
the change.  Forcing him to try to go through audit logs to figure out what 
happened is not sensible, particularly since network management is NOT this 
"user"s primary task.  he is a network engineer trying to fix a customer 
Whether this "user" is aware of the organizations desired policies is an 
organizational issue, not a protocol issue.  Making sure that there is 
someway to tell that he has overriden the policy (the flag that can be 
checked, and the logs to say who set the flag) is a protocol issue.

It may be that different organizations desire different behaviors in this 
regard.  Experience suggests to me however that the larger organizations 
which most want policy also have folks who need to make changes without 
significant hinderance.  And adding more options to the behavior does not 
seem like a good way out of this mess.  That will just give our users more 
ways to get confused.

Joel M. Halpern

At 12:23 PM 7/12/00 -0700, you wrote:

>All we're trying to do is make sure that when operators override a
>policy that they do so deliberately. Access control is not the
>right tool to accomplish this.
>If every operator has some more restrictive "root" priveleges and all
>objects require this new privelege, nothing has changed from an access
>control perspective and the same mistakes will be made.
>And administering fine-grained access control to restrict only those
>objects currently under policy control is a nightmare.
>Jon Saperia wrote:
> >
> > on 07/06/2000 5:23 PM, Steve Waldbusser at waldbusser@nextbeacon.com wrote:
> >
> > > All I want is for the field engineer to have to do something special
> > > to override a policy. Shouldn't he at least know that he has done
> > > something significant? Wouldn't it be good if he was thus encouraged
> > > to think twice? Wouldn't it be good if he was encouraged to mention it
> > > to the network architect? ("hey, I needed to disable the blah policy
> > > on trunk 7 last night because it was interacting poorly with the
> > > backup circuit").
> > >
> > > My proposal is that he issue 2 commands rather than one. The first
> > > disables the policy on the interface and the second is a normal
> > > SNMP set that makes the change.
> >
> > Steve, I am in agreement with your concern. I think we can accomplish this
> > without having to issue two commands though. You gave the example of not
> > running as 'root' to avoid making mistakes - most of us have learned that
> > lesson. My point is that the access/change of policy is an operational
> > policy (forgive the pun) decision. If a system is under policy control,
> > access to the MIB tree that contains everything except the policy objects,
> > should be quite restricted. The operator would then have to use the root
> > password to make the changes. This is analogous to 'su root' make all your
> > changes and exit. Your preference would be to have the person 'sudo change
> > 1', 'sudo change2' etc. In our case the equivalent of the sudo is to make
> > the explicit something special you suggest.