4. The manager polls the smScriptOperStatus object until the value is `editing'. 5. The manager sends SNMP set-requests to modify the script in the smCodeTable. 6. The manager sends a set-request to set the smScriptAdminStatus object to `enabled'. The Script MIB implementation now makes the script accessible to the runtime system. This might include the compilation of the script if the language requires a compilation step. 7. The manager polls the smScriptOperStatus object until the value is either `enabled' or one of the error status codes. The script can only be used if the value of smScriptOperStatus is `enabled'.
4. The manager sends a set-request to change smLaunchAdminStatus to `enabled' once the new smLaunchTable row is complete. 5. The manager polls the smLaunchOperStatus object until the value is `enabled'.
failed. The value `terminated' can be received in cases where the suspend operation failed and the running script terminated between the polls. Note that the set operation in the first step can lead to an inconsistentValue error which indicates that the suspend operation failed (e.g., because the runtime system does not support suspend/resume). There is no need to poll smRunState in this case.
The second way to terminate a script is to set the smRunLifeTime to zero which causes the runtime system to terminate the script with a `lifeTimeExceeded' exit code: 1. The manager changes the value of smRunLifeTime to 0. This causes the Script MIB implementation to abort the script because the remaining life time has expired. 2. The manager polls the smRunState object until the value is `terminated'. Note that changing the smRunLifeTime value can also be used to increase the permitted lifetime of a running script. For example, a manager can choose to set smRunLifeTime to a small fixed time interval and increase the value periodically. This strategy has the nice effect that scripts terminate automatically if the manager loses contact with the Script MIB engine. RFC2575] can be configured to control access to the Script MIB.
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.
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. RFC2434]. The Designated Expert will be selected by the IESG Area Director for the IETF Operations and Management Area.
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 RFC 2574 [RFC2574] and the View- based Access Control Model RFC 2575 [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 RFC 2575 [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. RFC 2592: - 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.
[RFC2571] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for Describing SNMP Management Frameworks", RFC 2571, April 1999. [RFC1155] Rose, M. and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based Internets", STD 16, RFC 1155, May 1990. [RFC1212] Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD 16, RFC 1212, March 1991. [RFC1215] Rose, M., "A Convention for Defining Traps for use with the SNMP", RFC 1215, 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, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC1157] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, May 1990. [RFC1901] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, January 1996. [RFC1906] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Transport Mappings for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1906, January 1996. [RFC2572] Case, J., Harrington D., Presuhn R. and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", RFC 2572, April 1999.
[RFC2574] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2574, April 1999. [RFC1905] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1905, January 1996. [RFC2573] Levi, D., Meyer, P. and B. Stewart, "SNMPv3 Applications", RFC 2573, April 1999. [RFC2575] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", RFC 2575, April 1999. [RFC2570] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction to Version 3 of the Internet-standard Network Management Framework", RFC 2570, April 1999. [RFC2028] Hovey, R. and S. Bradner, "The Organizations Involved in the IETF Standards Process", BCP 11, RFC 2028, October 1996. [RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter, " Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998. [RFC959] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC 959, 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", RFC 2616, June 1999. [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.