2001 #misc _____________________________________________________________________________ Topic: Resolutions Relevant Sections: Many Spec: Many _____________________________________________________________________________ RESOLUTION: bwg2001-001 Topic: NLSPATH Relevant Sections: catgets Spec: XBD5/XSH5 Resolution Request: ------------------- A potential security hole exists in gaining elevated privileges using the NLSPATH environment variable to specify a user supplied message catalog to be used by setuid applications. Resolution Response ------------------- The group resolved the following changes to XBD5 and XSH5 and corrigenda for the existing specifications as follows: In XBD5 (P96) and XBD4.2 (P95) change the paragraph: Users should not set the NLSPATH variable unless they have a specific reason to override the default system path. Doing so causes undefined behavior in the standard utilities. in the description of the NLSPATH Internationalisation Variable to say: Users should not set the NLSPATH variable unless they have a specific reason to override the default system path. Setting NLSPATH to override the default system path produces undefined results in the standard utilities and in applications with appropriate privileges." Add the following new error to the ERRORS section for the catgets() function on XSH5 P110 and XSH4v2 P73 between the entries for EBADF and EINTR: [EBADMSG] The message identified by set_id and msg_id in the specified message catalog did not satisfy implementation-dependent security criteria. Add the following new sentence: If NLSPATH exists in the environment when the process starts, then if the process has appropriate privileges, the behavior of catopen() is undefined. in the first paragraph of the DESCRIPTION section of catopen() in XSH5 on P112 and in XHS4v2 on P74 following the sentence starting with "If NLSPATH does not exist". Rationale ------------- None. Approved: March 2001 ========================================================================== RESOLUTION: 2001 #002 _____________________________________________________________________________ Topic: POLLWRBAND Relevant Sections: poll Spec: XSH5 Resolution Request: ------------------- The description of POLLWRBAND in XSH4v2's description of the poll() function was: POLLWRBAND Priority data (priority band greater than 0) may be written. This meant that poll would always set the POLLWRBAND flag unless all 255 priority bands were flow controlled. In practice, once a band had been written on SVR4.2 systems, POLLWRBAND only looked at bands that had been written, so SVR4.2 systems failed the original UNIX 95 tests. They got a waiver and a resolution was passed that resulted in the wording in XSH5: POLLWRBAND Priority data (priority band greater than 0) may be written. This event only examines bands that have been written to at least once. Although the test suite is testing this wording, we believe that this wording is more restrictive than was intended. We believe the intent was that POLLWRBAND flag should be set for any STREAMS file descriptor that has not yet had ANY priority band written to, or that can be written to on at least one band that has been written to. In practice, the SVr4 derived poll() implementations set POLLWRBAND for any STREAMS file descriptor before ANY priority band has been set (and for that reason fail this UNIX 98 test). After any priority band has been written to, they do set POLLWRBAND inspecting only bands that have been written to once. This behavior is important from the way application code is structured in general when used with poll(). Also, since most applications use only one priority band, this simple structure is sufficient to detect when they can write to a priority band. Applications that initialize communications channels to other processes want to be able to set up the STREAMS then set up a loop passing out requests on available channels. The test suite would require all of these applications to change to initialize the channels and use each channel once before going into the loop. This makes the initialization much harder for no gain for the applications. We request that a corrigenda or resolution be passed changing the last sentence of the XSH5 POLLWRBAND description from "This event only examines bands that have been written to at least once." to "If any priority band has been written to on this STREAM, this event only examines bands that have been written to at least once.". If such a change is eventually made, applications which rely on historic poll() behavior will not have to be changed and existing working applications will operate with XSH5 poll without any modifications. Resolution Response ------------------- Change XSHd5 p1353 27967 "This event only examines bands that have been written to at least once." to "If any priority band has been written to on this STREAM, this event only examines bands that have been written to at least once.". Add to Change History The DESCRIPTION of POLLWRBAND is updated as per The Open Group Issue corrigenda Rationale ------------- None. Approved: March 2001 ========================================================================== RESOLUTION: bwg2001-003 The Base WG resolves that having reviewed the use of the UN margin marker, the appropriate action is to remove the UN margin markers and shading. Approved. ========================================================================== RESOLUTION: bwg2001-004 The Base WG resolves that sin_zero be deleted, delete XBDd5 p292 line 10914 Add change history The sin_zero member was removed from the sockaddr_in structure Approved. ========================================================================== RESOLUTION: bwg2001-005 Resolved to remove the fds_bits member from the fd_set structure.
Approved. ========================================================================== RESOLUTION: bwg2001-006 The Base WG resolved to cleanup the versioning section of unistd.h removing the old baggage, and clearly defining the requirements for _XOPEN_VERSION. Approved. ========================================================================== RESOLUTION: bwg2001-007 The group resolved that the SCCS utilities be updated as per the following XCUd5 ERNs, 245,247,248,265,266,282,428 and 445 Approved. ========================================================================== _____________________________________________________________________________ Topic: namelen parameter Relevant Sections: gethostname Spec: XNS5.2 Resolution Request: ------------------- RESOLUTIION bwg2008-008 It was agreed to change the prototype for the namelen parameter for gethostname from socklen_t to size_t . This differs from XNS5.2 but matches XNS Issue 5. Approved: April 2001 ========================================================================== _____________________________________________________________________________ Topic: return type Relevant Sections: gai_strerror Spec: XNS5.2 RESOLUTIION bwg2001-009 It was agreed to change the return type for gai_strerror() to const char *. This is for coordination with the IPnG group. The change is from char *gai_strerror(int ecode); to const char *gai_strerror(int ecode); The rationale is that it returns string constants. Approved: April 2001 ========================================================================== RESOLUTION: bwg2001-009a (XCUd6 ERN 62 admin) The Base WG resolves to replace the text related to the -h option for the admin utility with the following: Check the structure of the SCCS file and compare the newly computed checksum with the checksum that is stored in the SCCS file. If the newly computed checksum does not match the checksum in the SCCS file, a diagnostic message shall be written. ========================================================================== _____________________________________________________________________________ Topic: chmod +t Relevant Sections: chmod Spec: XCU6 Base Working Group Resolution bwg2001-010 (revised 31 Jul 2002) ------------------------------------------ Insert the following replacement text for XCU6, P238, L9245-9248: The perm symbol t shall specify the S_ISVTX bit. When used with a file of type directory, it can be used with the who symbol a, or with no who symbol. It shall not be an error to specify a who symbol of u, g, or o in conjunction with the perm symbol t, but the meaning of these combinations is unspecified. The effect when using the perm symbol t with any file type other than directory is unspecified. Rationale: The original ERN and bwg2001-010 resulted in specifying behavior that diverges from the historical behavior on UNIX systems. The intent in adding the specification was to document existing behavior. This error may have been caused by a mix up with the who symbols u and o where its possible to read "o" out of context and think "owner" instead of "other". We believe where "o" is used below "u" ("user") should be specified and where u is used o should be specified. It also may be that the original ERN based its text on the gnu chmod o+t behavior for causing an executable to remain allocated on swap. For reference this is in section 3.2.3 of the gnu chmod page. This is not about the behavior of the "restriction deletion flag" for a directory. We have no objection to gnu chmod continuing supporting o+t behavior on an executable, nor the ignore u+t and g+t on non-directory files. We believe the above changes allow both historic and the gnu behavior. Approved: July 2002 (revised) ========================================================================== RESOLUTION: bwg2001-011 (XSHd6 ERN 26, exec) The Base WG resolves to make the following correction to the exec man page , as stated below: In XSHd6 page 754, exec: Replace lines 9606-9609 with: If the process image file is not a valid executable object, and the system does not recognize it as something that cannot be executed (and thus returns [EINVAL]), execlp() and execvp() shall execute a command interpreter and the environment of the executed command shall be as if the process invoked the sh utility using execl() as follows: execl( , arg0, file, arg1, ..., (char *)0); where is an unspecified pathname for the sh utility, and, for execvp(), where arg0, arg1, etc. correspond to the values passed to execvp() in argv, argv, etc. Approved ========================================================================== RESOLUTION: bwg2001-012 (IPv4 compatibility for IPv6 systems) The Base WG resolves to change the "may" in XSHd6 Section 184.108.40.206 Compatibility with IPv4 on page 518 line 2789 to a "shall". This is consistent with the intent. Approved ========================================================================== RESOLUTION: bwg2001-013 (lstat()/lchown()) The Base WG resolves to clarify the relationship between lchown() and lstat(), by adding the following application usage to lchown(). Add to APPLICATION USAGE of lchown() "On implementations which support symbolic links as directory entries rather than files, lchown() may fail." Rationale:This is not a normative change but adds additional text to stress the EOPNOTSUPP error on the lchown page. Approved ========================================================================== Topic: RLIMIT_NOFILE Relevant Sections: getrlimit Spec: XSH6 Base WG RESOLUTION: bwg2001-014 (getrlimit()) ======================= The Base WG resolves to change the description of RLIMIT_NOFILE in getrlimit() from: If this limit is exceeded, functions that allocate new file descriptors may fail with errno set to [EMFILE]. to: If this limit is exceeded, functions that allocate new file descriptors shall fail with errno set to [EMFILE]. Rationale: This is a change of "may fail" to "shall fail". The use of "may fail" is inconsistent with other parts of the standard which clearly require that an EMFILE error must occur when the RLIMIT_NOFILE soft limit is exceeded. The remainder of the description of RLIMIT_NOFILE is clear that when the soft limit has been reached, no more file descriptors can be opened. Therefore an attempt to open another file descriptor must fail, and according to section 2.3 "Error Numbers" (line 822), the errno value which is set when a failure occurs due to this condition cannot be different from the one described in XSH for that condition - i.e. it must be EMFILE. The referenced aardvark is: XSH ERN 26 (finaltext aardvark) Approved: May 23 2002