There has been an issue raised concerning the compatibility of POSIX.6 and POSIX.8. It has been alleged that POSIX.6 and POSIX.8 are ``fundamentally incompatible.'' The controversy arises over the relationship that POSIX.6 and POSIX.8 each have to POSIX.1. Briefly stated, POSIX.6 provides extensions to POSIX.1 and POSIX.8 makes optional some required features of POSIX.1. One of the goals of POSIX.8 is to permit access to as many file servers as possible even if those file servers cannot support all of the file characteristics required in POSIX.1.
The model that will most likely be used in a network environment is the client/server model. This model allows one system, a client, to access files and services on another system, the server. The most common use of this model is for a client to logically mount a file space on the server as a local drive on the client.
The first assumption that must be made here (and one that is not addressed by P1003.6) is that the requesting process is authenticated to be the claimed identity. Authentication is not addressed in P1003.1 or P1003.6. In a standalone environment, authentication is not an application portability issue. However in a networking environment, the case could be made that authentication is an application portability issue. P1003.6 did not originally address networking issues because P1003.6 interfaces are extensions to P1003.1, which did not address networking issues. This assumption of authentication, from a POSIX view, implies that it is a decision of the remote system (in this case the server) to add the additional requirement of authentication if need be.
The next issue common to both POSIX.6 and POSIX.8 is file access control. In order for a user to access a file from local or remote storage, the user must be granted permission from the file access control mechanism. The mandatory access control interfaces of POSIX.6 do not apply here because they specifically do not address mounted file systems. However the discretionary access control interfaces that support access control lists (ACLS) do apply. In POSIX.6, a file must have a group ID (GID) (which is required by POSIX.1) and may optionally have an access control list. In POSIX.8, a file may optionally have a GID. At first glance, the example implies a ``fundamental incompatibility.'' However, the important thing to note in the example is that in POSIX.6, the access control list is optional for each file on an individual basis, not for all files taken together. Similarly, in POSIX.8, the GID is optional for each file on an individual basis. A resolution of the alleged ``fundamental incompatibility'' is obvious and natural, i.e., if a file has an access control list, then it must have a GID, and if a file does not have an access control list, then it need not have a GID. This solution works only because the POSIX.8 specifications map the different file characteristics onto the POSIX.1 characteristics that the POSIX.6 interfaces expect.
There are other POSIX specifications that modify/enhance POSIX.1. The intent for each such specification is to merge these into one POSIX specification. This is not simply an editorial task. While the Working Groups are careful to avoid ``fundamental incompatibilities'' between their specifications, ambiguities will most certainly arise when the merge takes place.
In the meantime, is it possible for an implementation to be both POSIX.6 and POSIX.8 compliant? Since the ``fundamental incompatibilities'' illustrated in the example have an obvious resolution, an implementation can be made both POSIX.6 and POSIX.8 compliant. The key is to realize that those features of POSIX.6 that are extensions to POSIX.1 are optional on a per file basis and those features of POSIX.1 that are made optional in POSIX.8 are optional on a per file basis.