Standards Update (3 of 4): NBS FIPS
Moderator, John S. Quarterman
std-unix at longway.TIC.COM
Mon Jan 25 03:20:46 AEST 1988
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
More information about the Comp.std.unix
mailing list