Path: utzoo!mnetor!uunet!longway!std-unix From: std-unix@longway.TIC.COM (Moderator, John S. Quarterman) Newsgroups: comp.std.unix Subject: Standards Update (3 of 4): NBS FIPS Message-ID: <114@longway.TIC.COM> Date: 24 Jan 88 17:20:46 GMT Reply-To: std-unix@uunet.uu.net Lines: 270 Approved: jsq@longway.tic.com (Moderator, John S. Quarterman) Standards Update An update on UNIX and C Standards Activities January 21, 1988 Written for the USENIX Association by Shane P. McCarron, NAPS Inc. - NBS POSIX FIPS One other item that is of concern to system implementors and application developers alike is the POSIX FIPS that is being announced by NBS this month. This FIPS will be used by most federal agencies when drafting Request for Proposals (RFPs) for many classes of applications. Just what is NBS going to require? Well, the NBS POSIX FIPS is based on POSIX D12, the draft that went out to the balloting group. The final POSIX standard may be considerably different than this, but NBS has assured the .1 working group that they will incorporate the substantive changes in the standard into their FIPS when the standard is complete. So, if NBS is going to specify POSIX as the FIPS, what are we worried about? Well, in order to increase consensus and support as many existing implementations as possible, POSIX has a lot of "options" in it. NBS felt that these "options" made it difficult for applications developers to write applications that used the nice facilities of POSIX (they are right), so they are requiring that many of these options be included in a FIPS conforming implementation. For systems implementors, this means that you had better include all of these options if you want to sell to the federal government. For applications developers, it means that if your customer base is the federal government, you can use these facilities without fear - they will be there. What are these options? Well, the following is an excerpt from the NBS POSIX FIPS draft specification. As an aside, it is important to note that many of these so-called "options" are not really options at all, but rather cases in which there was some ambiguity as to how the system would function. I will indicate in the following list some examples of real options and their opposites for clarity. NBS FIPS, January 21, 1988 Shane P. McCarron, NAPS Inc. Standards Update - 2 - USENIX Association - The term appropriate privileges shall be synonymous with the term super-user. This is not really an option, but rather a clarification being introduced by the NBS people. The term "appropriate privileges" was introduced into the standard to provide for secure implementations of POSIX. By indicating that certain facilities of POSIX require "appropriate privilege", the door was left open for implementations where processes could have subsets of the power normally granted to a monolithic "super-user". In fact, the above requirement is incorrect. You could not simply replace the term "appropriate privileges" with the term "super- user" throughout the standard and have it make any sense. However, we get the idea. - A null pathname shall be considered invalid and generate an error (2.10.3, lines 894 - 896). - The use of the chown() function shall be restricted to a process with super-user privileges (2.10.4, lines 924 - 926). This is an example of a real option in POSIX. If the macro _POSIX_CHOWN_RESTRICTED is defined, it means that only a process with "appropriate privilege" can change to owner of a file. This is in conflict with the current System V definition of how chown works, btu is more in line with trusted implementations. Users should not be able to "give away" files. - Only the super-user shall be allowed to link or unlink directories (2.10.4, lines 938 - 939). Another useful option. A portable application may need to know whether it requires "approprite privileges" to move directories around. - The owner of a file may use the utime() function to set file timestamps to arbitrary values (2.10.4, lines 943 - 945). - The implementation shall support a value of {NGROUPS_MAX} greater than or equal to eight (8) (2.9.2). An implementation may provide an option for setting {NGROUPS_MAX} to a value other than eight (8). NBS FIPS, January 21, 1988 Shane P. McCarron, NAPS Inc. Standards Update - 3 - USENIX Association The POSIX standard is still in the ballot resolution process. When it went to ballot it defined the BSD-style supplementary groups feature. this says that there is a group-id associated with a process, but that there may be additional, supplementary groups also. As of this writing, the definition has been changed to a more flexible definition. There will now be an array of group IDs associated with a process. Although this change has not been accepted by the full balloting group yet, I think that it will be. - The implementation shall support the setting of the group-ID of a file (when it is created) to that of its parent directory (2.10.4, lines 934 - 937). An implementation may provide a programmable selectable means for setting the group-ID of a file (when it is created) to the effective group-ID of the creating process. This is another example of a true option. Here the FIPS is specifying the BSD method of creating files. This method make a lot of sense in a multiple group per process environment. However, they also allow the System V behavior. - The use of chown() shall be restricted to changing the group-ID of a file to the effective group-ID of a process or when {NGROUPS_MAX} > 0, to one of its supplementary group-IDs (2.10.4, lines 927 - 930). - The exec() type functions shall save the effective user- ID and group-ID (2.10.3, lines 902 - 903). This mirrors the System V behavior. - The kill() function shall use the saved set user- ID of the receiving process instead of the effective user-ID to determine eligibility to send the signal to a process (2.10.3, lines 891 - 893). This is also similar to System V. - When a session process group leader executes an exit() a SIGHUP signal shall be sent to each member of the session process group (2.10.3 lines 880 - 883). NBS FIPS, January 21, 1988 Shane P. McCarron, NAPS Inc. Standards Update - 4 - USENIX Association - The terminal special characters defined in Sections 7.1.1.10 and 7.1.2.7 can be individually disabled by using the value specified by _POSIX_V_DISABLE (2.10.4, lines 946 - 949; 7.1.1.10; 7.1.2.7). - The implementation shall support the _POSIX_JOB_CONTROL option 2.10.3, lines 884 - 886). Although I have not described how Job Control works under POSIX, suffice it to say that it is confusing at best. The ballot resolution group is still trying to decide how to resolve the problems pointed out during balloting. - The implementation shall provide a single utility for reading and writing POSIX data interchange format files (10.). This utility shall be capable of reading USTAR and CPIO data interchange formats without requiring the format to be specified. The implementation shall write CPIO data interchange format when no option on format type is specified. - Pathnames longer than {NAME_MAX} shall be considered invalid and generate an error (2.10.4, lines 940 - 942). - When the rename(), unlink() or rmdir() function is unsuccessful because the conditions for [EBUSY] occur, the implementation shall report the [EBUSY] errno (5.5.1.4, lines 481 - 482; 5.5.2.4, lines 523 - 524; 5.5.3.4, lines 593 - 594). - When the rename() function is unsuccessful because the conditions for [EXDEV] occur, the implementation shall report the [EXDEV] errno (5.5.3.4, lines 593 - 594). - When the fork() or exec type function is unsuccessful because the conditions for [ENOMEM] occur, the implementation shall report the [ENOMEM] errno (3.1.1.4, line 54; 3.1.2.4, lines 175 - 176). - When the getcwd() function is unsuccessful because the conditions for [EACCES] occur, the implementation shall report the [EACCES] errno (5.2.2.4, lines 148 - 149). NBS FIPS, January 21, 1988 Shane P. McCarron, NAPS Inc. Standards Update - 5 - USENIX Association - When the chown() or wait2() function is unsuccessful because the conditions for [EINVAL] occur, the implementation shall report the [EINVAL] errno (3.2.1.4, line 272; 5.6.5.4, line 857). - The implementation shall detect an [EFAULT] errno condition (2.5, lines 554 - 558). The implementation must state as part of the required documentation; (1) the conditions when an [EFAULT] is detected and an [EFAULT] errno is generated and (2) those conditions, if any, when [EFAULT] may not be detectable. - The tcsetattr() function shall only set the parameters supported by the underlying hardware associated with the terminal (7.2.1.2, line 502). - An interrupted write() function shall return a count of the number of bytes successfully transferred from the application program to the system (6.4.2.2, lines 195 - 196; 6.4.2.4. lines 240 - 242). - An implementation may provide errno [ENOEXIST] in place of errno [EACCES]. - A POSIX FIPS implementation shall successfully PASS the NBS-PCTS validation suite. From all of these options, I am sure that it is obvious that there is room for considerable variation in the POSIX standard. The FIPS goes a long way towards firming up an otherwise wishy-washy document. Since many system implementors want to sell to the US Government, it is probable that all of the above requirements will be available on a majority of POSIX conforming systems. This is excellent news for application developers who want to take advantage of some of the additional facilities introduced in POSIX as optional. NBS FIPS, January 21, 1988 Shane P. McCarron, NAPS Inc. Volume-Number: Volume 13, Number 4