The following is a description of the elements, types, and attributes that compose generic UNIX tests found in Open Vulnerability and Assessment Language (OVAL). Each test is an extension of the standard test element defined in the Core Definition Schema. Through extension, each test inherits a set of elements and attributes that are shared amongst all OVAL tests. Each test is described in detail and should provide the information necessary to understand what each element and attribute represents. This document is intended for developers and assumes some familiarity with XML. A high level description of the interaction between the different tests and their relationship to the Core Definition Schema is not outlined here.
The OVAL Schema is maintained by The Mitre Corporation and developed by the public OVAL Community. For more information, including how to get involved in the project and how to submit change requests, please visit the OVAL website at http://oval.mitre.org.
UNIX Definition
5.5
9/26/2008 7:31:00 AM
Copyright (c) 2002-2008, The MITRE Corporation. All rights reserved. The contents of this file are subject to the terms of the OVAL License located at http://oval.mitre.org/oval/about/termsofuse.html. See the OVAL License for the specific language governing permissions and limitations for use of this schema. When distributing copies of the OVAL Schema, this license header must be included.
The file test is used to check metadata associated with UNIX files, of the sort returned by either an ls command, stat command or stat() system call. It extends the standard TestType as defined in the oval-definitions-schema and one should refer to the TestType description for more information. The required object element references a file_object and the optional state element specifies the metadata to check. The evaluation of the test is guided by the check attribute that is inherited from the TestType.
The file_object element is used by a file test to define the specific file(s) to be evaluated. Each object extends the standard ObjectType as definied in the oval-definitions-schema and one should refer to the ObjectType description for more information. The common set element allows complex objects to be created using filters and set logic. Again, please refer to the description of the set element in the oval-definitions-schema.
A file object defines the path and filename of the file(s). In addition, a number of behaviors may be provided that help guide the collection of objects. Please refer to the FileBehaviors complex type for more information about specific behaviors.
The path element specifies the absolute path to a file on the machine.
- datatype attribute for the path entity of a file_object should be 'string'
The filename element specifies the name of a file to evaluate. If the nillable attribute is set to true, then the object being specified is the higher level directory object. (not all the files in the directory) In this case, the filename element should not be used during collection and would result in the set of collected objects being the directories themselves. For example, one would set nillable to true if the desire was to as test the attributes or permissions associated with a directory. Setting nil equal to true is different than using a .* pattern match, which says to collect every file under a given path.
- datatype attribute for the filename entity of a file_object should be 'string'
The file_state element defines the different metadata associate with a UNIX file. This includes the path, filename, type, group id, user id, size, etc. In addition, the permission associated with the file are also included. Please refer to the individual elements in the schema for more details about what each represents.
Specifies the absolute path to a file on the machine.
- datatype attribute for the path entity of a file_state should be 'string'
The name of the file.
- datatype attribute for the filename entity of a file_state should be 'string'
This is the file's type: regular file (regular), directory, named pipe (fifo), symbolic link, socket or block special.
- datatype attribute for the type entity of a file_state should be 'string'
The group_id entity represents the group owner of a file, by group number. To test for a file with no group assigned to it, this entity would be used with an empty value.
- datatype attribute for the group_id entity of a file_state should be 'string'
The numeric user id, or uid, is the third column of each user's entry in /etc/passwd. This element represents the owner of the file. To test for a file with no user assigned to it, this entity would be used with an empty value.
- datatype attribute for the user_id entity of a file_state should be 'string'
This is the time of the last access, in seconds since the last epoch.
- datatype attribute for the a_time entity of a file_state should be 'string'
This is the time of the last change to the file's inode, which stores all.
- datatype attribute for the c_time entity of a file_state should be 'string'
This is the time of the last change to the file's contents.
- datatype attribute for the m_time entity of a file_state should be 'string'
This is the size of the file in bytes.
- datatype attribute for the size entity of a file_state should be 'int'
Does the program run with the uid (thus privileges) of the file's owner, rather than the calling user?
- datatype attribute for the suid entity of a file_state should be 'boolean'
Does the program run with the gid (thus privileges) of the file's group owner, rather than the calling user's group?
- datatype attribute for the sgid entity of a file_state should be 'boolean'
Can users delete each other's files in this directory, when said directory is writable by those users?
- datatype attribute for the sticky entity of a file_state should be 'boolean'
Can the owner (user owner) of the file read this file or, if a directory, read the directory contents?
- datatype attribute for the uread entity of a file_state should be 'boolean'
Can the owner (user owner) of the file read this file or, if a directory, read the directory contents?
- datatype attribute for the uwrite entity of a file_state should be 'boolean'
Can the owner (user owner) of the file execute it or, if a directory, change into the directory?
- datatype attribute for the uexec entity of a file_state should be 'boolean'
Can the group owner of the file read this file or, if a directory, read the directory contents?
- datatype attribute for the gread entity of a file_state should be 'boolean'
Can the group owner of the file write to this file or directory?
- datatype attribute for the gwrite entity of a file_state should be 'boolean'
Can the group owner of the file execute it or, if a directory, change into the directory?
- datatype attribute for the gexec entity of a file_state should be 'boolean'
Can all other users read this file or, if a directory, read the directory contents?
- datatype attribute for the oread entity of a file_state should be 'boolean'
Can the other users write to this file or directory?
- datatype attribute for the owrite entity of a file_state should be 'boolean'
Can the other users execute this file or, if a directory, change into the directory?
- datatype attribute for the oexec entity of a file_state should be 'boolean'
These behaviors allow a more detailed definition of the file objects being specified.
'max_depth' defines how many directories to recurse when a recurse direction is specified. The default value is '-1' meaning no limitation. A value of '0' is equivalent to no recursion, '1' means to step only one directory level up/down, and so on.
The recurse attribute defines how to recurse into the PATH entity, in other words what to follow during recursion. Options includ symlinks, directories, or both. Note that a max-depth has be specified for recursion to take place and for this attribute to mean anything. The values of 'none', 'files', and 'files and directories' have been deprecated and will be removed in a future version since it is not possible to recures files.
'recurse_direction' defines the direction to recurse, either 'up' to parent directories, or 'down' into child directories. The default value is 'none' for no recursion.
'recurse_file_system' defines the file system limitation of any recursion, either 'local' limiting data collection to local file systems (as opposed to file systems mounted from an external system), or 'defined' to keep any recursion within the file system that the file_object (path+filename) has specified. The default value is 'all' meaning to use all available file systems for data collection.
The inetd test is used to check information associated with different Internet services. It extends the standard TestType as defined in the oval-definitions-schema and one should refer to the TestType description for more information. The required object element references an inetd_object and the optional state element specifies the information to check. The evaluation of the test is guided by the check attribute that is inherited from the TestType.
The inetd_object element is used by an inetd test to define the specific protocol-service to be evaluated. Each object extends the standard ObjectType as definied in the oval-definitions-schema and one should refer to the ObjectType description for more information. The common set element allows complex objects to be created using filters and set logic. Again, please refer to the description of the set element in the oval-definitions-schema.
An inetd object consists of a protocol entity and a service_name entity that identifies the specific service to be tested.
A recognized protocol listed in the file /etc/inet/protocols.
- datatype attribute for the protocol entity of an inetd_object should be 'string'
The name of a valid service listed in the services file. For RPC services, the value of the service-name field consists of the RPC service name or program number, followed by a '/' (slash) and either a version number or a range of version numbers (for example, rstatd/2-4).
- datatype attribute for the service_name entity of an inetd_object should be 'string'
The inetd_state element defines the different information associated with a specific Internet service. Please refer to the individual elements in the schema for more details about what each represents.
A recognized protocol listed in the file /etc/inet/protocols.
- datatype attribute for the protocol entity of an inetd_state should be 'string'
The name of a valid service listed in the services file. For RPC services, the value of the service-name field consists of the RPC service name or program number, followed by a '/' (slash) and either a version number or a range of version numbers (for example, rstatd/2-4).
- datatype attribute for the service_name entity of an inetd_state should be 'string'
Either the pathname of a server program to be invoked by inetd to perform the requested service, or the value internal if inetd itself provides the service.
- datatype attribute for the server_program entity of an inetd_state should be 'string'
- datatype attribute for the server_arguments entity of an inetd_state should be 'string'
- datatype attribute for the endpoint_type entity of an inetd_state should be 'string'
- datatype attribute for the exec_as_user entity of an inetd_state should be 'string'
This field has values wait or nowait. This entry specifies whether the server that is invoked by inetd will take over the listening socket associated with the service, and whether once launched, inetd will wait for that server to exit, if ever, before it resumes listening for new service requests.
- datatype attribute for the wait_status entity of an inetd_state should be 'string'
The interface test enumerate various attributes about the interfaces on a system. It extends the standard TestType as defined in the oval-definitions-schema and one should refer to the TestType description for more information. The required object element references an interface_object and the optional state element specifies the interface information to check. The evaluation of the test is guided by the check attribute that is inherited from the TestType.
The interface_object element is used by an interface test to define the specific interfaces(s) to be evaluated. Each object extends the standard ObjectType as definied in the oval-definitions-schema and one should refer to the ObjectType description for more information. The common set element allows complex objects to be created using filters and set logic. Again, please refer to the description of the set element in the oval-definitions-schema.
An interface object consists of a single name entity that identifies which interface is being specified.
The name element is the interface (eth0, eth1, fw0, etc.) name to check.
- datatype attribute for the name entity of an interface_object should be 'string'
The interface_state element enumerates the different properties associate with a Unix interface. Please refer to the individual elements in the schema for more details about what each represents.
The name element is the interface (eth0, eth1, fw0, etc.) name to check.
- datatype attribute for the name entity of an interface_state should be 'string'
The hardware_addr element is the hardware or MAC address of the physical network card.
- datatype attribute for the hardware_addr entity of an interface_state should be 'string'
This is the IP address of the interface.
- datatype attribute for the inet_addr entity of an interface_state should be 'string'
This is the broadcast IP address for this interface's network, like 192.168.255.255.
- datatype attribute for the broadcast_addr entity of an interface_state should be 'string'
This is the bitmask used to calculate the inteface's IP network. The network number is calculated by bitwise-ANDing this with the IP address. The host number on that network is calculated by bitwise-XORing this with the IP address.
- datatype attribute for the netmask entity of an interface_state should be 'string'
The flag entity represents the interface flag line, which generally contains flags like "UP" to denote an active interface, "PROMISC" to note that the interface is listening for Ethernet frames not specifically addressed to it, and others. This element can be included multiple times in a system characteristic item in order to record a multitude of flags. Note that the entity_check attribute associated with EntityStateStringType guides the evaluation of entities like this that refer to items that can occur an unbounded number of times.
- datatype attribute for a flag entity of an interface_state should be 'string'
/etc/passwd. See passwd(4).
The password test is used to check metadata associated with the UNIX password file, of the sort returned by the passwd command. It extends the standard TestType as defined in the oval-definitions-schema and one should refer to the TestType description for more information. The required object element references a password_object and the optional state element specifies the metadata to check. The evaluation of the test is guided by the check attribute that is inherited from the TestType.
The password_object element is used by a password test to define the object to be evaluated. Each object extends the standard ObjectType as definied in the oval-definitions-schema and one should refer to the ObjectType description for more information. The common set element allows complex objects to be created using filters and set logic. Again, please refer to the description of the set element in the oval-definitions-schema.
A password object consists of a single username entity that identifies the user whos passwords are to be evaluated.
- datatype attribute for the username entity of a password_object should be 'string'
The password_state element defines the different information associated with the system passwords. Please refer to the individual elements in the schema for more details about what each represents.
- datatype attribute for the username entity of a password_state should be 'string'
- datatype attribute for the password entity of a password_state should be 'string'
The numeric user id, or uid, is the third column of each user's entry in /etc/passwd. This element represents the owner of the file.
- datatype attribute for the user_id entity of a password_state should be 'string'
- datatype attribute for the group_id entity of a password_state should be 'string'
- datatype attribute for the gcos entity of a password_state should be 'string'
- datatype attribute for the home_dir entity of a password_state should be 'string'
- datatype attribute for the login_shell entity of a password_state should be 'string'
The process test is used to check information found in the UNIX processes. It is equivalent to parsing the output of the ps command. It extends the standard TestType as defined in the oval-definitions-schema and one should refer to the TestType description for more information. The required object element references a process_object and the optional state element specifies the process information to check. The evaluation of the test is guided by the check attribute that is inherited from the TestType.
The process_object element is used by a process test to define the specific process(es) to be evaluated. Each object extends the standard ObjectType as definied in the oval-definitions-schema and one should refer to the ObjectType description for more information. The common set element allows complex objects to be created using filters and set logic. Again, please refer to the description of the set element in the oval-definitions-schema.
A process object defines the command line used to start the process(s).
The command element specifies the command/program name to check.
- datatype attribute for the command entity of a process_object be 'string'
The process_state element defines the different metadata associate with a UNIX process. This includes the command line, pid, ppid, priority, and user id. Please refer to the individual elements in the schema for more details about what each represents.
The command element specifies the command/program name to check.
- datatype attribute for the command entity of a process_state should be 'string'
This is the cumulative CPU time, formatted in [DD-]HH:MM:SS where DD is the number of days when execution time is 24 hours or more.
- datatype attribute for the exec_time entity of a process_state should be 'string'
This is the process ID of the process.
- datatype attribute for the pid entity of a process_state should be 'int'
This is the process ID of the process's parent process.
- datatype attribute for the ppid entity of a process_state should be 'int'
This is the scheduling priority with which the process runs. This can be adjusted with the nice command or nice() system call.
- datatype attribute for the priority entity of a process_state should be 'string'
A platform specific characteristic maintained by the scheduler: RT (real-time), TS (timeshare), FF (fifo), SYS (system), etc.
- datatype attribute for the scheduling_class entity of a process_state should be 'string'
This is the time of day the process started formatted in HH:MM:SS if the same day the process started or formatted as MMM_DD (Ex.: Feb_5) if process started the previous day or further in the past.
- datatype attribute for the start_time entity of a process_state should be 'string'
This is the TTY on which the process was started, if applicable.
- datatype attribute for the tty entity of a process_state should be 'string'
The numeric user id, or uid, is the third column of each user's entry in /etc/passwd. It represents the owner, and thus privilege level, of the specified program.
- datatype attribute for the user_id entity of a process_state should be 'string'
The runlevel test is used to check information about which runlevel specified service are scheduled to exist at. For more information see the output generated by a chkconfig --list. It extends the standard TestType as defined in the oval-definitions-schema and one should refer to the TestType description for more information. The required object element references a runlevel_object and the optional state element specifies the data to check. The evaluation of the test is guided by the check attribute that is inherited from the TestType.
The runlevel_object element is used by a runlevel_test to define the specific service(s)/runlevel combination to be evaluated. Each object extends the standard ObjectType as definied in the oval-definitions-schema and one should refer to the ObjectType description for more information. The common set element allows complex objects to be created using filters and set logic. Again, please refer to the description of the set element in the oval-definitions-schema.
The service_name entity refers the name associated with a service. This name is usually the filename of the script file located in /etc/init.d directory.
- datatype attribute for the service_name entity of a runlevel_object be 'string'
The runlevel entity refers to which runlevel a system is at. A runlevel is defined as a software configuration of the system that allows only a selected group of processes to exist.
- datatype attribute for the runlevel entity of a runlevel_object be 'string'
The runlevel_state element holds information about whether a specific service is schedule to start or kill at a given runlevel. Please refer to the individual elements in the schema for more details about what each represents.
The service_name entity refers the name associated with a service. This name is usually the filename of the script file located in /etc/init.d directory.
- datatype attribute for the service_name entity of a runlevel_state should be 'string'
The runlevel entity refers to which runlevel a system is at. A runlevel is defined as a software configuration of the system that allows only a selected group of processes to exist.
- datatype attribute for the runlevel entity of a runlevel_state should be 'string'
The start entity determines if the process is scheduled to be spawned at the specified runlevel.
- datatype attribute for the start entity of a runlevel_state should be 'boolean'
The kill entity determines if the proces is supposed to be killed at the specified runlevel.
- datatype attribute for the kill entity of a runlevel_state should be 'boolean'
The path to an SCCS file.
- datatype attribute for the path entity of a sccs_object should be 'string'
The name of an SCCS file.
- datatype attribute for the filename entity of a sccs_object should be 'string'
- datatype attribute for the path entity of a sccs_state should be 'string'
This is the name of a SCCS file.
- datatype attribute for the filename entity of a sccs_state should be 'string'
- datatype attribute for the module_name entity of a sccs_state should be 'string'
- datatype attribute for the module_type entity of a sccs_state should be 'string'
- datatype attribute for the release entity of a sccs_state should be 'string'
- datatype attribute for the level entity of a sccs_state should be 'string'
- datatype attribute for the branch entity of a sccs_state should be 'string'
- datatype attribute for the sequence entity of a sccs_state should be 'string'
- datatype attribute for the what_string entity of a sccs_state should be 'string'
These behaviors allow a more detailed definition of the sccs objects being specified.
'max_depth' defines how many directories to recurse when a recurse direction is specified. The default value is '-1' meaning no limitation. A value of '0' is equivalent to no recursion, '1' means to step only one directory level up/down, and so on.
The recurse attribute defines how to recurse into the PATH entity, in other words what to follow during recursion. Options includ symlinks, directories, or both. Note that a max-depth has be specified for recursion to take place and for this attribute to mean anything. The values of 'none', 'files', and 'files and directories' have been deprecated and will be removed in a future version since it is not possible to recures files.
'recurse_direction' defines the direction to recurse, either 'up' to parent directories, or 'down' into child directories. The default value is 'none' for no recursion.
'recurse_file_system' defines the file system limitation of any recursion, either 'local' limiting data collection to local file systems (as opposed to file systems mounted from an external system), or 'defined' to keep any recursion within the file system that the file_object (path+filename) has specified. The default value is 'all' meaning to use all available file systems for data collection.
The shadow test is used to check information from the /etc/shadow file for a specific user. This file contains a user's password, but also their password aging and lockout information. It extends the standard TestType as defined in the oval-definitions-schema and one should refer to the TestType description for more information. The required object element references an inetd_object and the optional state element specifies the information to check. The evaluation of the test is guided by the check attribute that is inherited from the TestType.
The shadow_object element is used by a shadow test to define the shadow file to be evaluated. Each object extends the standard ObjectType as definied in the oval-definitions-schema and one should refer to the ObjectType description for more information. The common set element allows complex objects to be created using filters and set logic. Again, please refer to the description of the set element in the oval-definitions-schema.
A shdow object consists of a single user entity that identifies the username associted with the shadow file.
- datatype attribute for the username entity of a shadow_object should be 'string'
The shadows_state element defines the different information associated with the system shadow file. Please refer to the individual elements in the schema for more details about what each represents.
This is the name of the user being checked.
- datatype attribute for the username entity of a shadow_state should be 'string'
This is the encrypted version of the user's password.
- datatype attribute for the password entity of a shadow_state should be 'string'
This is the date of the last password change in days since 1/1/1970.
- datatype attribute for the chg_lst entity of a shadow_state should be 'string'
This specifies how often in days a user may change their password. It can also be thought of as the minimum age of a password.
- datatype attribute for the chg_allow entity of a shadow_state should be 'string'
This describes how long a user can keep a password before the system forces her to change it.
- datatype attribute for the chg_req entity of a shadow_state should be 'string'
This describes how long before password expiration the system begins warning the user. The system will warn the user at each login.
- datatype attribute for the exp_warn entity of a shadow_state should be 'string'
The exp_inact entity describes how many days of account inactivity the system will wait after a password expires before locking the account. Unix systems are generally configured to only allow a given password to last for a fixed period of time. When this time, the chg_req parameter, is near running out, the system begins warning the user at each login. How soon before the expiration the user receives these warnings is specified in exp_warn. The only hiccup in this design is that a user may not login in time to ever receive a warning before account expiration. The exp_inact parameter gives the sysadmin flexibility so that a user who reaches the end of their expiration time gains exp_inact more days to login and change their password manually.
- datatype attribute for the exp_inact entity of a shadow_state should be 'string'
This speicifies when will the account's password expire, in days since 1/1/1970.
- datatype attribute for the exp_date entity of a shadow_state should be 'string'
This is a reserved field that the shadow file may use in the future.
- datatype attribute for the flag entity of a shadow_state should be 'string'
The uname test reveals information about the hardware the machine is running on. This information is the parsed equivalent of uname -a. For example: "Linux quark 2.6.5-7.108-default #1 Wed Aug 25 13:34:40 UTC 2004 i686 i686 i386 GNU/Linux" or "Darwin TestHost 7.7.0 Darwin Kernel Version 7.7.0: Sun Nov 7 16:06:51 PST 2004; root:xnu/xnu-517.9.5.obj~1/RELEASE_PPC Power Macintosh powerpc". It extends the standard TestType as defined in the oval-definitions-schema and one should refer to the TestType description for more information. The required object element references a uname_object and the optional state element specifies the metadata to check. The evaluation of the test is guided by the check attribute that is inherited from the TestType.
The uname_object element is used by an uname test to define those objects to evaluated based on a specified state. There is actually only one object relating to uname and this is the system as a whole. Therefore, there are no child entities defined. Any OVAL Test written to check uname will reference the same uname_object which is basically an empty object element.
The uname_state element defines the information about the hardware the machine is running one. Please refer to the individual elements in the schema for more details about what each represents.
This entity specifies a machine hardware name. This corresponds to the command uname -m.
- datatype attribute for the machine_class entity of a uname_state should be 'string'
This entity specifies a host name. This corresponds to the command uname -n.
- datatype attribute for the node_name entity of a uname_state should be 'string'
This entity specifies an operating system name. This corresponds to the command uname -s.
- datatype attribute for the os_name entity of a uname_state should be 'string'
This entity specifies a build version. This corresponds to the command uname -r.
- datatype attribute for the os_release entity of a uname_state should be 'string'
This entity specifies an operating system version. This corresponds to the command uname -v.
- datatype attribute for the os_version entity of a uname_state should be 'string'
This entity specifies a processor type. This corresponds to the command uname -p.
- datatype attribute for the processor_type entity of a uname_state should be 'string'
The xinetd test is used to check information associated with different Internet services. It extends the standard TestType as defined in the oval-definitions-schema and one should refer to the TestType description for more information. The required object element references an inetd_object and the optional state element specifies the information to check. The evaluation of the test is guided by the check attribute that is inherited from the TestType.
The xinetd_object element is used by an xinetd test to define the specific protocol-service to be evaluated. Each object extends the standard ObjectType as definied in the oval-definitions-schema and one should refer to the ObjectType description for more information. The common set element allows complex objects to be created using filters and set logic. Again, please refer to the description of the set element in the oval-definitions-schema.
An xinetd object consists of a protocol entity and a service_name entity that identifies the specific service to be tested.
A recognized protocol.
- datatype attribute for the protocol entity of an xinetd_object should be 'string'
The name of a valid service.
- datatype attribute for the service_name entity of an xinetd_object should be 'string'
The xinetd_state element defines the different information associated with a specific Internet service. Please refer to the individual elements in the schema for more details about what each represents.
A recognized protocol.
- datatype attribute for the protocol entity of an xinetd_state should be 'string'
The name of a valid service.
- datatype attribute for the service_name entity of an xinetd_state should be 'string'
- datatype attribute for the flags entity of an xinetd_state should be 'string'
- datatype attribute for the no_access entity of an xinetd_state should be 'string'
- datatype attribute for the only_from entity of an xinetd_state should be 'string'
- datatype attribute for the port entity of an xinetd_state should be 'string'
- datatype attribute for the server entity of an xinetd_state should be 'string'
- datatype attribute for the server_arguments entity of an xinetd_state should be 'string'
- datatype attribute for the socket_type entity of an xinetd_state should be 'string'
- datatype attribute for the type entity of an xinetd_state should be 'string'
- datatype attribute for the user entity of an xinetd_state should be 'string'
- datatype attribute for the wait entity of an xinetd_state should be 'boolean'
- datatype attribute for the disabled entity of an xinetd_state should be 'boolean'
The EntityStateEndpointType complex type restricts a string value to a specific set of values that describe endpoint types associated with an Internet service. The empty string is also allowed to support empty emlement associated with variable references.
for a stream socket
for a datagram socket
for a raw socket
for a sequenced packet socket
for all TLI endpoints
The EntityXinetdTypeStatusType complex type restricts a string value to three values, either RPC, INTERNAL, or UNLISTED that specify the type of service registered in xinetd. The empty string is also allowed to support empty emlement associated with error conditions.
The INTERNAL type is used to describe services like echo, chargen, and others whose functionality is supplied by xinetd itself.
The RPC type is used to describe services that use remote procedure call ala NFS.
The UNLISTED type is used to describe services that aren't listed in /etc/protocols or /etc/rpc.
The EntityStateWaitStatusType complex type restricts a string value to two values, either wait or nowait, that specify whether the server that is invoked by inetd will take over the listening socket associated with the service, and whether once launched, inetd will wait for that server to exit, if ever, before it resumes listening for new service requests. The empty string is also allowed to support empty emlement associated with variable references.
The value of 'wait' specifies that the server that is invoked by inetd will take over the listening socket associated with the service, and once launched, inetd will wait for that server to exit, if ever, before it resumes listening for new service requests.
The value of 'nowait' specifies that the server that is invoked by inetd will not wait for any existing server to finish before taking over the listening socket associated with the service.