vacmAccessReadView."junior"."".usm.authNoPriv = "juniorReadView"
vacmAccessWriteView."junior"."".usm.authNoPriv = "juniorWriteView"
juniorReadView:
smLangTable (included)
smExtsnTable (included)
smScriptObjects.*.*.*."junior" (included)
smRunObjects.*.*.*."junior" (included)
smScriptObjects.*.*.*."utils" (included)
juniorWriteView:
smScriptObjects.*.*.*."junior" (included)
smRunObjects.*.*.*."junior" (included)
The definitions above allow the members of the "junior" VACM group to
start the scripts owned by "utils" in addition to the script the
members of the "junior" VACM group installed themselves. This is
accomplished by giving the members of "junior" read access to scripts
in "utils". This allows members of "junior" to create entries in the
smLaunchTable which refer to scripts in "utils", and to launch those
scripts using these entries in the smLaunchTable.
vacmAccessReadView."senior"."".usm.authNoPriv = "seniorReadView"
vacmAccessWriteView."senior"."".usm.authNoPriv = "seniorWriteView"
seniorReadView:
smLangTable (included)
smExtsnTable (included)
smScriptObjects.*.*.*."senior" (included)
smRunObjects.*.*.*."senior" (included)
smScriptObjects.*.*.*."utils" (included)
seniorWriteView:
smScriptObjects.*.*.*."senior" (included)
smRunObjects.*.*.*."senior" (included)
smScriptObjects.*.*.*."utils" (included)
The definitions for the members of the "senior" VACM group allow to
start the scripts owned by "utils" in addition to the script the
members of the "senior" VACM group installed themself. The third
write access rule in the seniorWriteView also grants the permission
to install scripts owned by "utils". The members of the "senior"
VACM group therefore have the permissions to install and modify
scripts that can be called by the members of the "junior" VACM group.
8.3. Emergency Scripts
This example demonstrates how VACM can be used to allow the members
of the "junior" VACM group to launch scripts that are executed with
the permissions associated with the "emergency" owner. This works by
adding the following rules to the juniorReadView and the
juniorWriteView:
juniorReadView:
smScriptObjects.*.*.*."emergency" (included)
smRunObjects.*.*.*."emergency" (included)
juniorWriteView
smLaunchStart."emergency" (included)
smLaunchArgument."emergency" (included)
The rules added to the juniorReadView grant read access to the
scripts, the launch buttons and the results owned by "emergency".
The rules added to the juniorWriteView grant write permissions to the
smLaunchStart and smLaunchArgument variables owned by "emergency".
Members of the "junior" VACM group can therefore start scripts that
will execute under the owner "emergency".
seniorReadView:
smScriptObjects.*.*.*."emergency" (included)
smRunObjects.*.*.*."emergency" (included)
seniorWriteView:
smScriptObjects.*.*.*."emergency" (included)
smRunObjects.*.*.*."emergency" (included)
The rules added to the seniorReadView and the seniorWriteView will
give the members of the "senior" VACM group the rights to install
emergency scripts and to configure appropriate launch buttons.
9. IANA Considerations
The Internet Assigned Numbers Authority (IANA) is responsible for
maintaining a MIB module (IANA-LANGUAGE-MIB) which provides OID
registrations for well-known languages. The IANA language registry
is intended to reduce interoperability problems by providing a single
list of well-known languages. However, it is of course still
possible to register languages in private OID spaces. Registering
languages in private OID spaces is especially attractive if a
language is used for experimentation or if a language is only used in
environments where the distribution of MIB modules with the language
registration does not cause any maintenance problems.
Any additions or changes to the list of languages registered via IANA
require Designated Expert Review as defined in the IANA guidelines
[RFC2434]. The Designated Expert will be selected by the IESG Area
Director for the IETF Operations and Management Area.
10. Security Considerations
There are a number of management objects defined in this MIB that
have a MAX-ACCESS clause of read-write and/or read-create. Such
objects may be considered sensitive or vulnerable in some network
environments. The support for SET operations in a non-secure
environment without proper protection can have a negative effect on
network operations.
SNMPv1 by itself is not a secure environment. Even if the network
itself is secure (for example by using IPSec), even then, there is no
control as to who on the secure network is allowed to access and
GET/SET (read/change/create/delete) the objects in this MIB.
It is recommended that the implementers consider the security
features as provided by the SNMPv3 framework. Specifically, the use
of the User-based Security Model RFC2574 [RFC2574] and the View-
based Access Control Model RFC2575 [RFC2575] is recommended.
It is then a customer/user responsibility to ensure that the SNMP
entity giving access to an instance of this MIB, is properly
configured to give access to the objects only to those principals
(users) that have legitimate rights to indeed GET or SET
(change/create/delete) them.
This MIB provides the ability to distribute applications written in
an arbitrary language to remote systems in a network. The security
features of the languages available in a particular implementation
should be taken into consideration when deploying an implementation
of this MIB.
To facilitate the provisioning of access control by a security
administrator using the View-Based Access Control Model (VACM)
defined in RFC2575 [RFC2575] for tables in which multiple users may
need to independently create or modify entries, the initial index is
used as an "owner index". Such an initial index has a syntax of
SnmpAdminString, and can thus be trivially mapped to a securityName
or groupName as defined in VACM, in accordance with a security
policy.
All entries in related tables belonging to a particular user will
have the same value for this initial index. For a given user's
entries in a particular table, the object identifiers for the
information in these entries will have the same subidentifiers
(except for the "column" subidentifier) up to the end of the encoded
owner index. To configure VACM to permit access to this portion of
the table, one would create vacmViewTreeFamilyTable entries with the
value of vacmViewTreeFamilySubtree including the owner index portion,
and vacmViewTreeFamilyMask "wildcarding" the column subidentifier.
More elaborate configurations are possible.
The VACM access control mechanism described above provides control
over SNMP access to Script MIB objects. There are a number of other
access control issues that are outside of the scope of this MIB. For
example, access control on URLs, especially those that use the file
scheme, must be realized by the underlying operating system. A
mapping of the owner index value to a local operating system security
user identity should be used by an implementation of this MIB to
control access to operating system resources when resolving URLs or
executing scripts.
11. Intellectual Property
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
12. Changes from RFC2592
The following list documents major changes from the previous version
of this document, published as RFC2592:
- Updated the boilerplate and the references.
- Added revision clauses to the module identity macro.
- Various typos have been fixed.
- Added SIZE restriction to smScriptName which is consistent with
smLaunchScriptName. Added DEFVAL and some clarifying text on the
usage of a zero-length string to smLaunchScriptName.
- Clarified under which conditions changes to smScriptLanguage are
invalid.
- Added new smScriptError and smLaunchError objects.
- Setting smRunLifeTime to its maximum value now disables the timer
so that scripts can run forever.
- Added the `autostart' value to the smLaunchAdminStatus object
which allows to launch scripts during the disable->enabled
transition of smLaunchOperStatus.
- Added an additional step to the "creating a launch button"
procedure which sets the smLaunchRowStatus to active.
- Added a final polling step in the procedure to launch a script.
- Added a final polling step in the procedure to terminate a running
script.
- Removed the requirement that smRunError is a zero-length string
while the smRunExitCode has the value `noError'.
- Added new smScriptLastChange, smLaunchLastChange, smRunResultTime,
and smRunErrorTime objects.
- Added some additional boilerplate text to the security
considerations section.
- Added a new smLaunchRowExpireTime object and a new `expired' state
to the smLaunchOperStatus object.
- Clarified that the smRunState object reports the actual state if
attempts to suspend or resume scripts fail.
- Clarified the conditions under which set operations to
smLaunchControl and smRunControl can lead to inconsistentValue
errors.
- Added procedures for suspending/resuming/removing running scripts
to section 7.
- Added text to the smScriptStorageType description to better
highlight the difference between the storage type of the script
row entry and the script itself.
- Updated the smCompliances statement to not require write access to
the smCodeText object after row creation.
- Deprecated smCompliance, smScriptGroup, smLaunchGroup, smRunGroup,
smNotificationsGroup and created smCompliance2, smScriptGroup2,
smLaunchGroup2, smRunGroup2 and smNotificationsGroup2 that take
care of the new objects and notifications.
13. Acknowledgments
This document was produced by the IETF Distributed Management
(DISMAN) working group.
14. References
[RFC2571] Harrington, D., Presuhn, R. and B. Wijnen, "An
Architecture for Describing SNMP Management Frameworks",
RFC2571, April 1999.
[RFC1155] Rose, M. and K. McCloghrie, "Structure and Identification
of Management Information for TCP/IP-based Internets", STD
16, RFC1155, May 1990.
[RFC1212] Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD
16, RFC1212, March 1991.
[RFC1215] Rose, M., "A Convention for Defining Traps for use with
the SNMP", RFC1215, March 1991.
[RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
Rose, M. and S. Waldbusser, "Structure of Management
Information Version 2 (SMIv2)", STD 58, RFC2578, April
1999.
[RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
Rose, M. and S. Waldbusser, "Textual Conventions for
SMIv2", STD 58, RFC2579, April 1999.
[RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
Rose, M. and S. Waldbusser, "Conformance Statements for
SMIv2", STD 58, RFC2580, April 1999.
[RFC1157] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "Simple
Network Management Protocol", STD 15, RFC1157, May 1990.
[RFC1901] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser,
"Introduction to Community-based SNMPv2", RFC1901,
January 1996.
[RFC1906] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser,
"Transport Mappings for Version 2 of the Simple Network
Management Protocol (SNMPv2)", RFC1906, January 1996.
[RFC2572] Case, J., Harrington D., Presuhn R. and B. Wijnen,
"Message Processing and Dispatching for the Simple Network
Management Protocol (SNMP)", RFC2572, April 1999.
[RFC2574] Blumenthal, U. and B. Wijnen, "User-based Security Model
(USM) for version 3 of the Simple Network Management
Protocol (SNMPv3)", RFC2574, April 1999.
[RFC1905] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser,
"Protocol Operations for Version 2 of the Simple Network
Management Protocol (SNMPv2)", RFC1905, January 1996.
[RFC2573] Levi, D., Meyer, P. and B. Stewart, "SNMPv3 Applications",
RFC2573, April 1999.
[RFC2575] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based
Access Control Model (VACM) for the Simple Network
Management Protocol (SNMP)", RFC2575, April 1999.
[RFC2570] Case, J., Mundy, R., Partain, D. and B. Stewart,
"Introduction to Version 3 of the Internet-standard
Network Management Framework", RFC2570, April 1999.
[RFC2028] Hovey, R. and S. Bradner, "The Organizations Involved in
the IETF Standards Process", BCP 11, RFC2028, October
1996.
[RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter, " Uniform
Resource Identifiers (URI): Generic Syntax", RFC2396,
August 1998.
[RFC959] Postel, J. and J. Reynolds, "File Transfer Protocol", STD
9, RFC959, October 1985.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC2616, June 1999.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC2434,
October 1998.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC2119, March 1997.
15. Editors' Addresses
David B. Levi
Nortel Networks
4401 Great America Parkway
Santa Clara, CA 95052-8185
USA
Phone: +1 423 686 0432
EMail: dlevi@nortelnetworks.com
Juergen Schoenwaelder
TU Braunschweig
Bueltenweg 74/75
38106 Braunschweig
Germany
Phone: +49 531 391-3283
EMail: schoenw@ibr.cs.tu-bs.de
16. Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFCEditor function is currently provided by the
Internet Society.