Andrew Josey
2014-05-23 13:32:56 UTC
All
Enclosed are the minutes of the 22nd May 2014 Teleconference
regards
Andrew
----
Minutes of the 22nd May 2014 Teleconference Austin-656 Page 1 of 1
Submitted by Andrew Josey, The Open Group. 23rd May 2014
Attendees:
Richard Hansen, BBN (~15 mins late)
Martin Rehak, Oracle (first hour)
Mark Ziegast, SHware Systems
Andrew Josey, The Open Group
Geoff Clare, The Open Group
Eric Blake, Red Hat
Nick Stoughton, USENIX, ISO/IEC JTC 1/SC 22 OR (few minutes late)
Joerg Schilling FOKUS Fraunhofer
Don Cragun, IEEE PASC OR
Mark Brown, Canonical
David Clissold, IBM
* General news
Andrew has an action to check the interpretations pending queue
and commence any new interpretations reviews.
(Update: after the meeting a 30 day review was started for bugs 838,839)
* Outstanding actions
+Bug 0000251: Forbid newline, or even bytes 1 through 31 (inclusive), in filenames OPEN
http://austingroupbugs.net/view.php?id=251
Don has an action to produce a proposal.
+Bug 0000561: NUL-termination of sun_path in Unix sockets OPEN
http://austingroupbugs.net/view.php?id=561
Eric has an action to update the proposal.
+Bug 0000573: Please add '+' to the portable filename character set OPEN
http://austingroupbugs.net/view.php?id=573
Joerg has an action to prepare a proposed change.
+Bug 0000592: consistent use of struct timespec OPEN
http://austingroupbugs.net/view.php?id=592
Jim had provided additional information in bugnote 1627.
This was discussed and Jim took an action to provide further information.
+Bug 0000598: OH shading and new interfaces OPEN
http://austingroupbugs.net/view.php?id=598
Eric has an action to propose a new solution with self-contained headers.
+Bug 0000517: EBNF support OPEN
http://austingroupbugs.net/view.php?id=517
Action on Joerg to look at this.
+Bug 0000633: SIGEV_THREAD delivery renders many signal interfaces unsafe
OPEN
http://austingroupbugs.net/view.php?id=633
We noted that feedback has settled down on the mailing list, and
will discuss next session.
+Bug 0000657: Conditions under which fmemopen() write a NUL to the buffer
are insufficiently specified OPEN
http://austingroupbugs.net/view.php?id=657
Eric has an action to propose wording to clarify the behavior for
fmemopen(), and also to contact the glibc developers to get their
feedback.
+Bug 0000658: Undefined/unspecified behavior clauses in description of
open have race conditions OPEN
http://austingroupbugs.net/view.php?id=658
It was noted that there is some overlap with changes in TC1. Eric took an
action to update the proposal to resolve the overlaps appropriately.
+Bug 0000615: pthread_setcancelstate should be async-signal-safe OPEN
http://austingroupbugs.net/view.php?id=615
We now have reports on AIX and Apple. Jim to report back on whether
pthread_cancelstate() is async-signal-safe on Solaris. Andrew to ask
HP whether pthread_cancelstate() is async-signal-safe on HP-UX.
+Bug 622 left open pending resolution of 615.
http://austingroupbugs.net/view.php?id=622
+Bug 0000672: Necessary step(s) to synchronize filename operations on disk
OPEN
http://austingroupbugs.net/view.php?id=672
Geoff has a new proposed resolution in note 1618. Decided to solicit input
from FS developers. Eric to go to Linux, David to AIX and Jim to Solaris.
Jim has completed his action (see bugnote 1691).
Andrew should chase HP and Apple for input.
+Bug 0000663: Specification of str[n]casecmp is ambiguous reopened
http://austingroupbugs.net/view.php?id=663
Action on David to follow up with the IBM developers about the EBCDIC
collation sequence.
Bug 696 either NAME_MAX shouldn't be optional, or readdir_r() needs clarification
http://www.austingroupbugs.net/view.php?id=696
Don has an action to propose a resolution.
Bug 0000721: Internal storage vs static storage OPEN
http://austingroupbugs.net/view.php?id=721
This item is still open.
Bug 0000375: Extend test/[...] conditionals: ==, <, >, -nt, -ot, -ef OPEN
http://austingroupbugs.net/view.php?id=375
This is still left open due to discussions pending on the reflector.
Bug 0000789: Add set -o pipefail OPEN
http://austingroupbugs.net/view.php?id=789
* Current Business
Bug #811: precondition for mutex destruction unclear; example contradicts normative text OPEN
http://www.austingroupbugs.net/view.php?id=811
We have left this item open pending further input from Dave Butenhof on
supplying a new example.
Bug 0000838: Unclear wording about how real IDs are used Accepted as Marked
http://austingroupbugs.net/view.php?id=838
Geoff had completed his action from the previous meeting.
An interpretation is required
This item is tagged for TC2-2008
Interpretation response:
The standard clearly states that access() checks file accessibility
using the real user ID and real group ID in place of the effective
IDs, and conforming implementations must conform to this.
Rationale:
The standard requires that access() uses the real user ID and group ID
instead of the effective IDs when checking file accessibility, and this
applies to all aspects of accessibility that would normally be based
on the effective IDs, including directory permission checks during
pathname resolution. It also affects any appropriate privileges that
are granted based on user or group ID and any alternate or additional
file access control mechanisms that are based on user or group IDs.
Notes to the Editor (not part of this interpretation):
At page 565 line 9576 section access() change:
... for accessibility according to the bit pattern contained
in amode, using the real user ID in place of the effective user
ID and the real group ID in place of the effective group ID.
to:
... for accessibility according to the bit pattern contained
in amode. The checks for accessibility (including directory
permissions checked during pathname resolution) shall be performed
using the real user ID in place of the effective user ID and
the real group ID in place of the effective group ID.
At page 565 line 19584 section access() change:
The faccessat() function shall be equivalent to the access()
function, except ...
to:
The faccessat() function when called with a flag value of zero
shall be equivalent to the access() function, except ...
At page 565 line 19595 section access() change:
The checks for accessibility are performed using the effective
user and group IDs instead of the real user and group ID
to:
The checks for accessibility (including directory permissions
checked during pathname resolution) shall be performed using
the effective user ID and group ID instead of the real user ID
and group ID
At page 566 line 19643 section access() add the following paragraphs to the beginning of the APPLICATION USAGE section:
Use of these functions is discouraged since by the time the
returned information is acted upon, it is out of date. (That
is, acting upon the information always leads to a
time-of-check-to-time-of-use race condition.) An application
should instead attempt the action itself and handle the EACCES
error that occurs if the file is not accessible (with a change
of effective user and group IDs beforehand, and perhaps a change
back afterwards, in the case where access() or faccessat()
without AT_EACCES would have been used.)
Historically, one of the uses of access() was in set-user-ID
root programs to check whether the user running the program had
access to a file. This relied on "super-user" privileges which
were granted based on the effective user ID being zero, so that
when access() used the real user ID to check accessibility those
privileges were not taken into account. On newer systems where
privileges can be assigned which have no association with user
or group IDs, if a program with such privileges calls access(),
the change of IDs has no effect on the privileges and therefore
they are taken into account in the accessibility checks. Thus
access() (and faccessat() with flag zero) cannot be used for
this historical purpose in such programs. Likewise, if a system
provides any additional or alternate file access control
mechanisms that are not user ID based, they will still be taken
into account.
If a relative pathname is used, no account is taken of whether
the current directory (or the directory associated with the
file descriptor fd) is accessible via any absolute pathname.
Applications using access(), or faccessat() without AT_EACCES,
may consequently act as if the file would be accessible to a
user with the real user ID and group ID of the process when
such a user would not in practice be able to access the file
because access would be denied at some point above the current
directory (or the directory associated with the file descriptor
fd) in the file hierarchy.
If access() or faccessat() is used with W_OK to check for write
access to a directory which has the S_ISVTX bit set, a return
value indicating the directory is writable can be misleading
since some operations on files in the directory would not be
permitted based on the ownership of those files (see [xref to
XBD 4.2]).
At page 567 line 19672 section access() change FUTURE DIRECTIONS from:
None.
to:
These functions may be formally deprecated (for example by
shading them OB) in a future revision of this standard.
Bug #000839 problems with reduction of WORD to ASSIGNMENT_WORD Accepted as Marked
http://austingroupbugs.net/view.php?id=839
An interpretation is required
This item is tagged for TC2-2008
Interpretation response
------------------------
The standard is unclear on this issue, and no conformance distinction can be made between alternative implementations based on this. This is being referred to the sponsor.
Rationale:
-------------
None.
Notes to the Editor (not part of this interpretation):
-------------------------------------------------------
After applying the changes in 0000643, change XCU 2.10.2 (Shell Grammar Rules) rule 7.b. page 2349 lines 74755-74761 from:
If the TOKEN contains the <equals-sign> character:
* If it begins with '=', the token WORD shall be returned.
* If all the characters in the TOKEN preceding the first '='
form a valid name (see XBD Section 3.231), the token
ASSIGNMENT_WORD shall be returned. (Quoted characters cannot
participate in forming a valid name.)
* Otherwise, it is unspecified whether it is ASSIGNMENT_WORD or
WORD that is returned.
to:
If the TOKEN contains an unquoted (as determined while applying
rule #4 from section 2.3) <equals-sign> character that is not part
of an embedded parameter expansion, command substitution, or
arithmetic expansion construct (as determined while applying rule
#5 from section 2.3):
* If the TOKEN begins with '=', then rule 1 shall be applied.
* If all the characters in the TOKEN preceding the first such
<equals-sign> form a valid name (see XBD Section 3.231), the
token ASSIGNMENT_WORD shall be returned.
* Otherwise, it is unspecified whether rule 1 is applied or
ASSIGNMENT_WORD is returned.
Otherwise, rule 1 shall be applied.
Bug #622: Disallow loophole for asynchronous cancellation of any function OPEN
http://austingroupbugs.net/view.php?id=622
This item is awaiting resolution of #615, which we progressed to.
Bug #615: pthread_setcancelstate should be async-signal-safe OPEN
http://austingroupbugs.net/view.php?id=615
Previously we were waiting on action items, and now it looks like
some of the action items have been completed.
HPUX's pthread_setcancelstate is not async-signal-safe.
Linux's man page doesn't say either way.
Neither does NetBSD's.
It is proposed that for issue 7 tc2: we add to future directions
that a future version of the standard may make it async-signal-safe.
We will continue discussing this next week.
Next Steps
----------
The next call is on May 29, 2014 (a Thursday)
Calls are anchored on US time. (8am Pacific)
This call will be for the regular 90 minutes.
http://austingroupbugs.net
An IRC channel will be available for the meeting
irc://irc.freenode.net/austingroupbugs
An etherpad is usually up for the meeting, with a URL using the date format as below:
http://posix-aA9aGynHYqB/thfjNshNs9i2O/***@public.gmane.org:9001/p/201x-mm-dd
password=2115756#
--------
Andrew Josey The Open Group
Austin Group Chair Apex Plaza, Forbury Road
Email: a.josey-7882/***@public.gmane.org Reading,Berks.RG1 1AX,England
Tel:+44 118 9023044 US fax: +1 415 276 3760
Mobile:+44 774 015 5794 UK fax: +44 870 131 0418
Enclosed are the minutes of the 22nd May 2014 Teleconference
regards
Andrew
----
Minutes of the 22nd May 2014 Teleconference Austin-656 Page 1 of 1
Submitted by Andrew Josey, The Open Group. 23rd May 2014
Attendees:
Richard Hansen, BBN (~15 mins late)
Martin Rehak, Oracle (first hour)
Mark Ziegast, SHware Systems
Andrew Josey, The Open Group
Geoff Clare, The Open Group
Eric Blake, Red Hat
Nick Stoughton, USENIX, ISO/IEC JTC 1/SC 22 OR (few minutes late)
Joerg Schilling FOKUS Fraunhofer
Don Cragun, IEEE PASC OR
Mark Brown, Canonical
David Clissold, IBM
* General news
Andrew has an action to check the interpretations pending queue
and commence any new interpretations reviews.
(Update: after the meeting a 30 day review was started for bugs 838,839)
* Outstanding actions
+Bug 0000251: Forbid newline, or even bytes 1 through 31 (inclusive), in filenames OPEN
http://austingroupbugs.net/view.php?id=251
Don has an action to produce a proposal.
+Bug 0000561: NUL-termination of sun_path in Unix sockets OPEN
http://austingroupbugs.net/view.php?id=561
Eric has an action to update the proposal.
+Bug 0000573: Please add '+' to the portable filename character set OPEN
http://austingroupbugs.net/view.php?id=573
Joerg has an action to prepare a proposed change.
+Bug 0000592: consistent use of struct timespec OPEN
http://austingroupbugs.net/view.php?id=592
Jim had provided additional information in bugnote 1627.
This was discussed and Jim took an action to provide further information.
+Bug 0000598: OH shading and new interfaces OPEN
http://austingroupbugs.net/view.php?id=598
Eric has an action to propose a new solution with self-contained headers.
+Bug 0000517: EBNF support OPEN
http://austingroupbugs.net/view.php?id=517
Action on Joerg to look at this.
+Bug 0000633: SIGEV_THREAD delivery renders many signal interfaces unsafe
OPEN
http://austingroupbugs.net/view.php?id=633
We noted that feedback has settled down on the mailing list, and
will discuss next session.
+Bug 0000657: Conditions under which fmemopen() write a NUL to the buffer
are insufficiently specified OPEN
http://austingroupbugs.net/view.php?id=657
Eric has an action to propose wording to clarify the behavior for
fmemopen(), and also to contact the glibc developers to get their
feedback.
+Bug 0000658: Undefined/unspecified behavior clauses in description of
open have race conditions OPEN
http://austingroupbugs.net/view.php?id=658
It was noted that there is some overlap with changes in TC1. Eric took an
action to update the proposal to resolve the overlaps appropriately.
+Bug 0000615: pthread_setcancelstate should be async-signal-safe OPEN
http://austingroupbugs.net/view.php?id=615
We now have reports on AIX and Apple. Jim to report back on whether
pthread_cancelstate() is async-signal-safe on Solaris. Andrew to ask
HP whether pthread_cancelstate() is async-signal-safe on HP-UX.
+Bug 622 left open pending resolution of 615.
http://austingroupbugs.net/view.php?id=622
+Bug 0000672: Necessary step(s) to synchronize filename operations on disk
OPEN
http://austingroupbugs.net/view.php?id=672
Geoff has a new proposed resolution in note 1618. Decided to solicit input
from FS developers. Eric to go to Linux, David to AIX and Jim to Solaris.
Jim has completed his action (see bugnote 1691).
Andrew should chase HP and Apple for input.
+Bug 0000663: Specification of str[n]casecmp is ambiguous reopened
http://austingroupbugs.net/view.php?id=663
Action on David to follow up with the IBM developers about the EBCDIC
collation sequence.
Bug 696 either NAME_MAX shouldn't be optional, or readdir_r() needs clarification
http://www.austingroupbugs.net/view.php?id=696
Don has an action to propose a resolution.
Bug 0000721: Internal storage vs static storage OPEN
http://austingroupbugs.net/view.php?id=721
This item is still open.
Bug 0000375: Extend test/[...] conditionals: ==, <, >, -nt, -ot, -ef OPEN
http://austingroupbugs.net/view.php?id=375
This is still left open due to discussions pending on the reflector.
Bug 0000789: Add set -o pipefail OPEN
http://austingroupbugs.net/view.php?id=789
* Current Business
Bug #811: precondition for mutex destruction unclear; example contradicts normative text OPEN
http://www.austingroupbugs.net/view.php?id=811
We have left this item open pending further input from Dave Butenhof on
supplying a new example.
Bug 0000838: Unclear wording about how real IDs are used Accepted as Marked
http://austingroupbugs.net/view.php?id=838
Geoff had completed his action from the previous meeting.
An interpretation is required
This item is tagged for TC2-2008
Interpretation response:
The standard clearly states that access() checks file accessibility
using the real user ID and real group ID in place of the effective
IDs, and conforming implementations must conform to this.
Rationale:
The standard requires that access() uses the real user ID and group ID
instead of the effective IDs when checking file accessibility, and this
applies to all aspects of accessibility that would normally be based
on the effective IDs, including directory permission checks during
pathname resolution. It also affects any appropriate privileges that
are granted based on user or group ID and any alternate or additional
file access control mechanisms that are based on user or group IDs.
Notes to the Editor (not part of this interpretation):
At page 565 line 9576 section access() change:
... for accessibility according to the bit pattern contained
in amode, using the real user ID in place of the effective user
ID and the real group ID in place of the effective group ID.
to:
... for accessibility according to the bit pattern contained
in amode. The checks for accessibility (including directory
permissions checked during pathname resolution) shall be performed
using the real user ID in place of the effective user ID and
the real group ID in place of the effective group ID.
At page 565 line 19584 section access() change:
The faccessat() function shall be equivalent to the access()
function, except ...
to:
The faccessat() function when called with a flag value of zero
shall be equivalent to the access() function, except ...
At page 565 line 19595 section access() change:
The checks for accessibility are performed using the effective
user and group IDs instead of the real user and group ID
to:
The checks for accessibility (including directory permissions
checked during pathname resolution) shall be performed using
the effective user ID and group ID instead of the real user ID
and group ID
At page 566 line 19643 section access() add the following paragraphs to the beginning of the APPLICATION USAGE section:
Use of these functions is discouraged since by the time the
returned information is acted upon, it is out of date. (That
is, acting upon the information always leads to a
time-of-check-to-time-of-use race condition.) An application
should instead attempt the action itself and handle the EACCES
error that occurs if the file is not accessible (with a change
of effective user and group IDs beforehand, and perhaps a change
back afterwards, in the case where access() or faccessat()
without AT_EACCES would have been used.)
Historically, one of the uses of access() was in set-user-ID
root programs to check whether the user running the program had
access to a file. This relied on "super-user" privileges which
were granted based on the effective user ID being zero, so that
when access() used the real user ID to check accessibility those
privileges were not taken into account. On newer systems where
privileges can be assigned which have no association with user
or group IDs, if a program with such privileges calls access(),
the change of IDs has no effect on the privileges and therefore
they are taken into account in the accessibility checks. Thus
access() (and faccessat() with flag zero) cannot be used for
this historical purpose in such programs. Likewise, if a system
provides any additional or alternate file access control
mechanisms that are not user ID based, they will still be taken
into account.
If a relative pathname is used, no account is taken of whether
the current directory (or the directory associated with the
file descriptor fd) is accessible via any absolute pathname.
Applications using access(), or faccessat() without AT_EACCES,
may consequently act as if the file would be accessible to a
user with the real user ID and group ID of the process when
such a user would not in practice be able to access the file
because access would be denied at some point above the current
directory (or the directory associated with the file descriptor
fd) in the file hierarchy.
If access() or faccessat() is used with W_OK to check for write
access to a directory which has the S_ISVTX bit set, a return
value indicating the directory is writable can be misleading
since some operations on files in the directory would not be
permitted based on the ownership of those files (see [xref to
XBD 4.2]).
At page 567 line 19672 section access() change FUTURE DIRECTIONS from:
None.
to:
These functions may be formally deprecated (for example by
shading them OB) in a future revision of this standard.
Bug #000839 problems with reduction of WORD to ASSIGNMENT_WORD Accepted as Marked
http://austingroupbugs.net/view.php?id=839
An interpretation is required
This item is tagged for TC2-2008
Interpretation response
------------------------
The standard is unclear on this issue, and no conformance distinction can be made between alternative implementations based on this. This is being referred to the sponsor.
Rationale:
-------------
None.
Notes to the Editor (not part of this interpretation):
-------------------------------------------------------
After applying the changes in 0000643, change XCU 2.10.2 (Shell Grammar Rules) rule 7.b. page 2349 lines 74755-74761 from:
If the TOKEN contains the <equals-sign> character:
* If it begins with '=', the token WORD shall be returned.
* If all the characters in the TOKEN preceding the first '='
form a valid name (see XBD Section 3.231), the token
ASSIGNMENT_WORD shall be returned. (Quoted characters cannot
participate in forming a valid name.)
* Otherwise, it is unspecified whether it is ASSIGNMENT_WORD or
WORD that is returned.
to:
If the TOKEN contains an unquoted (as determined while applying
rule #4 from section 2.3) <equals-sign> character that is not part
of an embedded parameter expansion, command substitution, or
arithmetic expansion construct (as determined while applying rule
#5 from section 2.3):
* If the TOKEN begins with '=', then rule 1 shall be applied.
* If all the characters in the TOKEN preceding the first such
<equals-sign> form a valid name (see XBD Section 3.231), the
token ASSIGNMENT_WORD shall be returned.
* Otherwise, it is unspecified whether rule 1 is applied or
ASSIGNMENT_WORD is returned.
Otherwise, rule 1 shall be applied.
Bug #622: Disallow loophole for asynchronous cancellation of any function OPEN
http://austingroupbugs.net/view.php?id=622
This item is awaiting resolution of #615, which we progressed to.
Bug #615: pthread_setcancelstate should be async-signal-safe OPEN
http://austingroupbugs.net/view.php?id=615
Previously we were waiting on action items, and now it looks like
some of the action items have been completed.
HPUX's pthread_setcancelstate is not async-signal-safe.
Linux's man page doesn't say either way.
Neither does NetBSD's.
It is proposed that for issue 7 tc2: we add to future directions
that a future version of the standard may make it async-signal-safe.
We will continue discussing this next week.
Next Steps
----------
The next call is on May 29, 2014 (a Thursday)
Calls are anchored on US time. (8am Pacific)
This call will be for the regular 90 minutes.
http://austingroupbugs.net
An IRC channel will be available for the meeting
irc://irc.freenode.net/austingroupbugs
An etherpad is usually up for the meeting, with a URL using the date format as below:
http://posix-aA9aGynHYqB/thfjNshNs9i2O/***@public.gmane.org:9001/p/201x-mm-dd
password=2115756#
--------
Andrew Josey The Open Group
Austin Group Chair Apex Plaza, Forbury Road
Email: a.josey-7882/***@public.gmane.org Reading,Berks.RG1 1AX,England
Tel:+44 118 9023044 US fax: +1 415 276 3760
Mobile:+44 774 015 5794 UK fax: +44 870 131 0418