This appendix provides an overview of the POSIX standards that are relevant to DODIIS standards efforts. POSIX standards are monitored to identify changes that may affect DODIIS standards in the future. This appendix is not all inclusive of all the POSIX committees that have been established, but is a description of the committees that are currently viewed as relevant in the DODIIS standards effort.
Since there is a major realignment of POSIX nomenclature it is necessary to also to discuss the nomenclature used for standards produced by the POSIX committees. Most POSIX efforts have been moved to become subcategories under three standards areas:
The POSIX realignment has also eliminated some POSIX standards efforts and realigned some of the standards efforts into special categories. Table B-1 reflect the latest status of all POSIX standards as of this publication. The realignment may make it more difficult to track specific standards issues that are of interest to DODIIS. For example, Remote Procedure Calls , (RPCs) are now part of the POSIX kernel specification and Security specifications are split between POSIX.1 and POSIX.2. The bright side of the new POSIX standards alignment is that issues of roles and coordination between POSIX committees appears to be more consistent.
Table B-1. POSIX Standards Realignment Status
POSIX.0 provides an overview of all the standards efforts that are established for the POSIX effort. The guide provides the basic information that is needed to identify possible standards candidates for establishing implementation profiles and is intended for that purpose. The guide will have to be constantly updated to reflect changes from all the POSIX committees. The POSIX.0 guide is intended to be used by anyone needing to use standards to construct an information processing system including users, systems integrators, application developers, system providers, and procurement agencies.
POSIX.0 maps existing standards onto general requirements of a complete information processing system. In addition to listing current standards efforts, the guide identifies important requirements that are not currently addressed by standards. In those areas where requirements are not met by formal standards, the guide identifies emerging standards and existing public specifications. Emerging standards and public specifications are not part of the POSIX Open System Environment (OSE), but are noted to identify existing work and possible Gap fillers to fill requirements until standards and compliant products become available.
The System Application Programming Interface (API) is currently an official standard of IEEE and ISO, as defined by ISO/IEC 9945-1:1990, respectively. This interface is documented in FIPS PUB 151-2. DODIIS will require that operating systems implement the more recent IEEE/ISO standard, reflective of the restrictions defined in FIPS PUB 151-2. Each version of operating systems purchased for DODIIS must have a current POSIX conformance statement verified by placement on the NIST list of POSIX certified systems.
Meanwhile, the IEEE POSIX.1 committee is continuing to pursue additional functionality for the System API and to develop a language-independent specification (LIS). POSIX.1 is currently dependent upon the C programming language. LIS efforts have been moved to P1372, and are continuing outside the scope of the current POSIX kernel API efforts (see section B.12). When these changes are formalized and are incorporated as FIPS PUBS, they will be evaluated for inclusion in the DODIIS Profile. Ada bindings are specified in POSIX.5a and POSIX.5b will be identified in the context of the POSIX LIS document P1372.
The Command and Utilities Interface is defined in IEEE P1003.2:1992 which was approved in October 1992. This standard is based largely on AT&T's Bourne Shell and includes facilities for developing scripts (command files) and also includes an API to a set of functions that are callable from the C programming language. User portability (the ability of users to move between computers and use a consistent interactive interface) is being addressed by the User Portability Extension (UPE) to the Command and Utilities Interface. Because IEEE P1003.2:1992 allows for the use of obsolescent features, NIST has published FIPS PUB 189. This publication references the IEEE standard, but removes the obsolescent features.
DODIIS operating systems will be required to pass IEEE P2003.1-1991, Standard for Information Technology - Test Methods for Measuring Conformance to POSIX. Compliance testing has already been defined for the POSIX.1 System API standard as part of a POSIX Conformance Test Suite (PCTS) developed by NIST/IEEE. Tests for other POSIX interfaces will be developed and required as the interfaces are defined. P2003 discusses overall test methods, P2003.1 discusses test assertions for P1003.1, and P2003.2 discusses test assertions for P1003.2.
Originally IEEE P1003.6, real-time services has been realigned under the POSIX kernel specification (P1003.1). IEEE P1003.1d provides real-time extensions needed to address realtime services. Realtime extensions addresses the following areas: 1) high resolution timers; 2) priority scheduling; 3) shared memory; 4) real-time files; 5) semaphores; 6) interprocess communications; 7) asynchronous event notification; 8) process memory locking; 9) asynchronous input/output; and 10) synchronous input/output. The current real-time specification includes a C language binding and thread extensions.
Until recently, the POSIX project as a whole has focused primarily on the C programming language bindings to POSIX interfaces. The POSIX.5 committee is defining equivalent bindings for the Ada programming language. However, these efforts are minimal, with priority being given to completion of POSIX using C programming language bindings or language independent specifications. Therefore, POSIX.5a, Ada Language Bindings for POSIX Interfaces, will not be required for DODIIS until POSIX.5b is completed, products are available, and integration with other components of the DODIIS architecture is feasible.
POSIX security standards will define a standard interface and environment for computer systems that require a secure environment and is intended for system implementors and application software developers. POSIX security standards will be split to functional components complementary to POSIX.1, POSIX.2, and P1387 standards. Other IEEE standards assume the underlying operating system conforms to the POSIX security which will define five, independent, optional security mechanisms that will become integrated into the ISO/IEC 9945-1: 1990 (System Application Program Interface) standard, the ISO/IEC 9945-2 (Shell and Utilities) and ultimately the ISO/IEC 9945-3 (System Administration) standards as they are published and approved. These mechanisms are access control lists (ACLs), security auditing, least privilege, mandatory access control (MAC), and information labeling.
Since the purpose of POSIX security is to provide for application portability between conforming systems, security requirements in areas that do not pertain to application portability will not be addressed. These include identification and authentication, network services and protocols, administrative services and management of security information, configuration management, convert channels, and assurance issues.
The objective of the System Administration standard is to define a functionally complete way of managing multiple networked, heterogeneous systems in a consistent manner. Because even de facto standards in this area do not exist, the POSIX.7 is taking a fresh approach to the problem by basing their work on object-oriented technology. These efforts, though, are still in the draft phase, and the technical direction of this future standard is currently being accomplished in small steps in areas that can be well defined. The first version of P1387 is centered on user administration, print administration and software management. Additional systems management areas such as data archiving will be added as they become well defined.
When the System Administration standard is completed, it will be required by DODIIS. Until then, the system administration tools that are available from the vendor of the operating system are recommended. Note: an alternative solution for larger sites would be to procure a third party system administration tool; this approach may be satisfactory in the very near term, but the incorporation of security, particularly CMWs, may disallow the continued use of such a tool.
A transparent file access (TFA) capability is a fundamental part of the DODIIS technical infrastructure. Furthermore, the TFA committee is pursuing the definition of a TFA that will be compliant with the full semantics of the POSIX.1 file system. Realignment of the POSIX efforts places TFA as a subsection of POSIX.1, namely P1003.1f. Currently, the de facto industry standard for a TFA capability is Sun Microsystem's Network File System (NFS) and Open Software Foundations (OSF) Distributed File System (DFS) which is part of the OSF integrated Distributed Computing Environment (DCE). Because there is so much momentum behind NFS as a de facto standard, the TFA standard will include a subset TFA definition which will permit NFS to be used while remaining consistent with the definition of the full TFA standard. DODIIS operating systems will be required to implement the TFA standard when it is completed and commercially available.
Interprocess communication includes local (within the same computer) and remote (networked) communications. For interprocess communications, the P1003.1g committee is defining two APIs that correspond to the Transport Layer of the OSI network reference model. One API, called the Detailed Network Interface (DNI), will provide access to the full flexibility of the network. The second API, called the Simple Network Interface (SNI), will provide a simpler interface, but reduced flexibility. Compatibility with existing de facto industry standards such as Berkeley Sockets, X/Open's XTI, and Unix International's TLI is a goal of the Interprocess communication committee.
The P1003.1g Interprocess Communication standards are not mature, with only DNI currently specified. This specification requires rigorous coordination with other POSIX groups. As an interim solution, DODIIS will require that developed applications use the Berkeley Sockets or X/Open's XTI interface for interprocess communication.
Originally POSIX standards were specified based on the constructs of the C programming language. There has been significant change to focus on developing all POSIX documents as language independent specifications that provide the required functional statements independent of the syntax and semantics of any programming language. The language standards groups are then responsible for providing the standard bindings (syntax and semantics) for their language to the language independent POSIX environment. P1372 is an effort to normalize the original C based POSIX specifications to a language independent declaration that will be used to update later versions of ISO/IEC 9945-1.
Directory Services Application Programming Interface standards, (P1224.2), formerly POSIX.17, define how objects (i.e., data, applications, and other resources) are cataloged, managed, and located in a networked environment. There is a lack of existing standards in this area, although the ITU-TSS X.500 series of recommendations will probably form a prominent part of P1224.2 efforts. Until there is clear direction from P1224.2, and commercial products become available DODIIS will recommend that existing practices be used (i.e., the TCP/IP-based Domain Name System). DNS transition strategies may impact current DODIIS directory services plans and there may be an immediate need to transition to X.500 at some sites. Any new starts must consider transition paths between DNS and X.500.