home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.13 / text0003.txt < prev    next >
Encoding:
Text File  |  1988-04-18  |  11.0 KB  |  272 lines
  1.  
  2.                       Standards Update
  3.         An update on UNIX and C Standards Activities
  4.  
  5.                       January 21, 1988
  6.  
  7.              Written for the USENIX Association
  8.               by Shane P. McCarron, NAPS Inc.
  9.  
  10.    - NBS POSIX FIPS
  11.  
  12.      One other item that is of concern to system
  13.      implementors and application developers alike is the
  14.      POSIX FIPS that is being announced by NBS this month.
  15.      This FIPS will be used by most federal agencies when
  16.      drafting Request for Proposals (RFPs) for many classes
  17.      of applications.
  18.  
  19.      Just what is NBS going to require?  Well, the NBS POSIX
  20.      FIPS is based on POSIX D12, the draft that went out to
  21.      the balloting group.  The final POSIX standard may be
  22.      considerably different than this, but NBS has assured
  23.      the .1 working group that they will incorporate the
  24.      substantive changes in the standard into their FIPS
  25.      when the standard is complete.
  26.  
  27.      So, if NBS is going to specify POSIX as the FIPS, what
  28.      are we worried about?  Well, in order to increase
  29.      consensus and support as many existing implementations
  30.      as possible, POSIX has a lot of "options" in it.  NBS
  31.      felt that these "options" made it difficult for
  32.      applications developers to write applications that used
  33.      the nice facilities of POSIX (they are right), so they
  34.      are requiring that many of these options be included in
  35.      a FIPS conforming implementation.  For systems
  36.      implementors, this means that you had better include
  37.      all of these options if you want to sell to the federal
  38.      government.  For applications developers, it means that
  39.      if your customer base is the federal government, you
  40.      can use these facilities without fear - they will be
  41.      there.
  42.  
  43.      What are these options?  Well, the following is an
  44.      excerpt from the NBS POSIX FIPS draft specification.
  45.  
  46.      As an aside, it is important to note that many of these
  47.      so-called "options" are not really options at all, but
  48.      rather cases in which there was some ambiguity as to
  49.      how the system would function.  I will indicate in the
  50.      following list some examples of real options and their
  51.      opposites for clarity.
  52.  
  53. NBS FIPS, January 21, 1988      Shane P. McCarron, NAPS Inc.
  54.  
  55.  
  56. Standards Update           - 2 -          USENIX Association
  57.  
  58.         - The term appropriate privileges shall be
  59.           synonymous with the term super-user.
  60.  
  61.           This is not really an option, but rather a
  62.           clarification being introduced by the NBS people.
  63.           The term "appropriate privileges" was introduced
  64.           into the standard to provide for secure
  65.           implementations of POSIX.  By indicating that
  66.           certain facilities of POSIX require "appropriate
  67.           privilege", the door was left open for
  68.           implementations where processes could have subsets
  69.           of the power normally granted to a monolithic
  70.           "super-user".  In fact, the above requirement is
  71.           incorrect.  You could not simply replace the term
  72.           "appropriate privileges" with the term "super-
  73.           user" throughout the standard and have it make any
  74.           sense.  However, we get the idea.
  75.  
  76.         - A null pathname shall be considered invalid and
  77.           generate an error (2.10.3, lines 894 - 896).
  78.  
  79.         - The use of the chown() function shall be
  80.           restricted to a process with super-user privileges
  81.           (2.10.4, lines 924 - 926).
  82.  
  83.           This is an example of a real option in POSIX.  If
  84.           the macro _POSIX_CHOWN_RESTRICTED is defined, it
  85.           means that only a process with "appropriate
  86.           privilege" can change to owner of a file.  This is
  87.           in conflict with the current System V definition
  88.           of how chown works, btu is more in line with
  89.           trusted implementations.  Users should not be able
  90.           to "give away" files.
  91.  
  92.         - Only the super-user shall be allowed to link or
  93.           unlink directories (2.10.4, lines 938 - 939).
  94.  
  95.           Another useful option.  A portable application may
  96.           need to know whether it requires "approprite
  97.           privileges" to move directories around.
  98.  
  99.         - The owner of a file may use the utime() function
  100.           to set file timestamps to arbitrary values
  101.           (2.10.4, lines 943 - 945).
  102.  
  103.         - The implementation shall support a value of
  104.           {NGROUPS_MAX} greater than or equal to eight (8)
  105.           (2.9.2).  An implementation may provide an option
  106.           for setting {NGROUPS_MAX} to a value other than
  107.           eight (8).
  108.  
  109. NBS FIPS, January 21, 1988      Shane P. McCarron, NAPS Inc.
  110.  
  111.  
  112. Standards Update           - 3 -          USENIX Association
  113.  
  114.           The POSIX standard is still in the ballot
  115.           resolution process.  When it went to ballot it
  116.           defined the BSD-style supplementary groups
  117.           feature.  this says that there is a group-id
  118.           associated with a process, but that there may be
  119.           additional, supplementary groups also.
  120.  
  121.           As of this writing, the definition has been
  122.           changed to a more flexible definition.  There will
  123.           now be an array of group IDs associated with a
  124.           process.  Although this change has not been
  125.           accepted by the full balloting group yet, I think
  126.           that it will be.
  127.  
  128.         - The implementation shall support the setting of
  129.           the group-ID of a file (when it is created) to
  130.           that of its parent directory (2.10.4, lines 934 -
  131.           937).  An implementation may provide a
  132.           programmable selectable means for setting the
  133.           group-ID of a file (when it is created) to the
  134.           effective group-ID of the creating process.
  135.  
  136.           This is another example of a true option.  Here
  137.           the FIPS is specifying the BSD method of creating
  138.           files.  This method make a lot of sense in a
  139.           multiple group per process environment.  However,
  140.           they also allow the System V behavior.
  141.  
  142.         - The use of chown() shall be restricted to changing
  143.           the group-ID of a file to the effective group-ID
  144.           of a process or when {NGROUPS_MAX} > 0, to one of
  145.           its supplementary group-IDs (2.10.4, lines 927 -
  146.           930).
  147.  
  148.         - The exec() type functions shall save the effective
  149.           user- ID and group-ID (2.10.3, lines 902 - 903).
  150.  
  151.           This mirrors the System V behavior.
  152.  
  153.         - The kill() function shall use the saved set user-
  154.           ID of the receiving process instead of the
  155.           effective user-ID to determine eligibility to send
  156.           the signal to a process (2.10.3, lines 891 - 893).
  157.  
  158.           This is also similar to System V.
  159.  
  160.         - When a session process group leader executes an
  161.           exit() a SIGHUP signal shall be sent to each
  162.           member of the session process group (2.10.3 lines
  163.           880 - 883).
  164.  
  165. NBS FIPS, January 21, 1988      Shane P. McCarron, NAPS Inc.
  166.  
  167.  
  168. Standards Update           - 4 -          USENIX Association
  169.  
  170.         - The terminal special characters defined in
  171.           Sections 7.1.1.10 and 7.1.2.7 can be individually
  172.           disabled by using the value specified by
  173.           _POSIX_V_DISABLE (2.10.4, lines 946 - 949;
  174.           7.1.1.10;  7.1.2.7).
  175.  
  176.         - The implementation shall support the
  177.           _POSIX_JOB_CONTROL option 2.10.3, lines 884 -
  178.           886).
  179.  
  180.           Although I have not described how Job Control
  181.           works under POSIX, suffice it to say that it is
  182.           confusing at best.  The ballot resolution group is
  183.           still trying to decide how to resolve the problems
  184.           pointed out during balloting.
  185.  
  186.         - The implementation shall provide a single utility
  187.           for reading and writing POSIX data interchange
  188.           format files (10.).  This utility shall be capable
  189.           of reading USTAR and CPIO data interchange formats
  190.           without requiring the format to be specified.  The
  191.           implementation shall write CPIO data interchange
  192.           format when no option on format type is specified.
  193.  
  194.         - Pathnames longer than {NAME_MAX} shall be
  195.           considered invalid and generate an error (2.10.4,
  196.           lines 940 - 942).
  197.  
  198.         - When the rename(), unlink() or rmdir() function is
  199.           unsuccessful because the conditions for [EBUSY]
  200.           occur, the implementation shall report the [EBUSY]
  201.           errno (5.5.1.4, lines 481 - 482; 5.5.2.4, lines
  202.           523 - 524; 5.5.3.4, lines 593 - 594).
  203.  
  204.         - When the rename() function is unsuccessful because
  205.           the conditions for [EXDEV] occur, the
  206.           implementation shall report the [EXDEV] errno
  207.           (5.5.3.4, lines 593 - 594).
  208.  
  209.         - When the fork() or exec type function is
  210.           unsuccessful because the conditions for [ENOMEM]
  211.           occur, the implementation shall report the
  212.           [ENOMEM] errno (3.1.1.4, line 54; 3.1.2.4, lines
  213.           175 - 176).
  214.  
  215.         - When the getcwd() function is unsuccessful because
  216.           the conditions for [EACCES] occur, the
  217.           implementation shall report the [EACCES] errno
  218.           (5.2.2.4, lines 148 - 149).
  219.  
  220. NBS FIPS, January 21, 1988      Shane P. McCarron, NAPS Inc.
  221.  
  222.  
  223. Standards Update           - 5 -          USENIX Association
  224.  
  225.         - When the chown() or wait2() function is
  226.           unsuccessful because the conditions for [EINVAL]
  227.           occur, the implementation shall report the
  228.           [EINVAL] errno (3.2.1.4, line 272; 5.6.5.4, line
  229.           857).
  230.  
  231.         - The implementation shall detect an [EFAULT] errno
  232.           condition (2.5, lines 554 - 558). The
  233.           implementation must state as part of the required
  234.           documentation; (1) the conditions when an [EFAULT]
  235.           is detected and an [EFAULT] errno is generated and
  236.           (2) those conditions, if any, when [EFAULT] may
  237.           not be detectable.
  238.  
  239.         - The tcsetattr() function shall only set the
  240.           parameters supported by the underlying hardware
  241.           associated with the terminal (7.2.1.2, line 502).
  242.  
  243.         - An interrupted write() function shall return a
  244.           count of the number of bytes successfully
  245.           transferred from the application program to the
  246.           system (6.4.2.2, lines 195 - 196; 6.4.2.4. lines
  247.           240 - 242).
  248.  
  249.         - An implementation may provide errno [ENOEXIST] in
  250.           place of errno [EACCES].
  251.  
  252.         - A POSIX FIPS implementation shall successfully
  253.           PASS the NBS-PCTS validation suite.
  254.  
  255.      From all of these options, I am sure that it is obvious
  256.      that there is room for considerable variation in the
  257.      POSIX standard.  The FIPS goes a long way towards
  258.      firming up an otherwise wishy-washy document.  Since
  259.      many system implementors want to sell to the US
  260.      Government, it is probable that all of the above
  261.      requirements will be available on a majority of POSIX
  262.      conforming systems.  This is excellent news for
  263.      application developers who want to take advantage of
  264.      some of the additional facilities introduced in POSIX
  265.      as optional.
  266.  
  267. NBS FIPS, January 21, 1988      Shane P. McCarron, NAPS Inc.
  268.  
  269.  
  270. Volume-Number: Volume 13, Number 4
  271.  
  272.