Base WG Resolution Ref: bwg2001-001 ... 014

This is a set of approved Base Working Group Resolutions

								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
    [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".


Approved: March 2001


RESOLUTION: 2001 #002


	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

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


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.

RESOLUTION: bwg2001-004
The Base WG resolves that sin_zero[8] be deleted, delete
XBDd5	p292 line 10914
Add change history
The sin_zero member was removed from the sockaddr_in structure

RESOLUTION: bwg2001-005
Resolved to remove the fds_bits member from the fd_set

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.

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



	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);
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.


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[0], argv[1], etc.

RESOLUTION: bwg2001-012 (IPv4 compatibility for IPv6 systems)
The Base WG resolves to change the "may" in
XSHd6 Section Compatibility with IPv4 on  page 518
line 2789 to a "shall". This is consistent with the intent.


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.


	Relevant Sections:	getrlimit
	Spec:			XSH6

Base WG RESOLUTION: bwg2001-014 (getrlimit())

The Base WG resolves to change the description of RLIMIT_NOFILE
in getrlimit()

        If this limit is exceeded, functions that allocate new file
        descriptors may fail with errno set to [EMFILE].

        If this limit is exceeded, functions that allocate new file
        descriptors shall fail with errno set to [EMFILE].

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