[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: snmpconf Comments on BCP-09
on the following...
At 06:56 PM 8/5/2002 -0700, Randy Presuhn wrote:
>> 6) Fine grained access control assignment - a desirable property
>> is to allow management apps to create resource instances
>> via an SNMP set, and to gain "exclusive" or "owner" access
>> as found in file creation operations found in many operating
>> systems, such as the Unix variants. However, the VACM-based
>> access control is VERY different than Unix-like file access
>This is by design. VACM's requirements are quite different
>from those for a file system. For example, VACM needs to
>be able to represent an access control policy for things
>independent of whether the specific instance exists at the
Yes, the property of VACM to create "access policys" that refer
to instances that don't yet exist is a good property. The limitation
of VACM to not being able to directly support "set access to x"
on create for creator's group is a problem with VACM.
>> A design pattern was introduced in the MIB modules
>> from the DISMAN WG which attempted to mimic the Unix-like
>> access control behavior on creation.
>No. As much as I dislike the implicit delegation approach
>that shows up in several disman MIBs (inherited with mutations
>from RMON) I must say that it was *not* intended to mimic
>Unix semantics. The Unix concept of "setuid" was used to
>illustrate one of the things that one might want to support,
>but the extent of the relationship was that existing practice
>for scripts and scheduling in Unix was used to help understand
>what the requirements and use cases might be.
>> This design pattern
>> is flawed (and many have not yet realized it). Please
>> describe the objective, show the MIB design pattern and
>> describe how it is flawed.
>If you have a proposal to fix the currently deployed
>specifications, please take it to the disman WG. Until those
>specifications are fixed, they remain, for better or worse,
>the "best current practice."
>> (Note that another design pattern
>> to give fined grained access control is found in table
>> usmUserTable in RFC 2574.) The pluses and minuses of
>> the design pattern used there should be pointed out.
>The kludgy *OwnKeyChange objects have a very special purpose,
>and the kludginess was deemed acceptable in the interest of
>keeping VACM reasonably scalable. Using that approach would
>be really bad news in other MIBs, since none of the published
>subagent protocols would support it, as far as I know, and there
>was not sufficient interest in the AgentX WG to do anything
Again, understanding of both the pluses and minus of an approach
allows us to make better future choices. Maybe some of those
choices with be a better master/sub-agent interface.
/david t. perkins