Minutes of the 26th May 2022 Teleconference Austin-1225 Page 1 of 1 Submitted by Andrew Josey, The Open Group. 29th May 2022 Attendees: Mark Ziegast, SHware Systems Dev. Don Cragun, IEEE PASC OR Nick Stoughton, Logitech/USENIX, ISO/IEC JTC 1/SC 22 OR Eric Blake, Red Hat, The Open Group OR Geoff Clare, The Open Group Eric Ackermann, HPI, University of Potsdam Andrew Josey, The Open Group * General news This was a call dedicated to general bugs. A reminder that there will be no calls on May 30th and June 2nd. * Outstanding actions Bug 1533: struct tm: add tm_gmtoff (and tm_zone) field(s) OPEN https://austingroupbugs.net/bug_view_page.php?bug_id=1533 This was discussed in the February 3, 2022 teleconference. Leave it open until we get a more complete suggestion for the Desired Action. * Current Business Bug 1560: clarify wording of command substitution OPEN https://austingroupbugs.net/view.php?id=1560 Leave this and related bugs 1561, and 1564 open pending reviews/discussions. Bug 906: Ambiguity of abort() behavior racing with sigaction OPEN https://austingroupbugs.net/view.php?id=906 (carried forward from the last meeting) Action on Nick to raise this issue with the C committee. Does threads.h and Section 5 address it in C11/17/2x somehow? Bug 922: Implementations should be allowed to change/remove implementation-defined environment variables Accepted as Marked https://austingroupbugs.net/view.php?id=922 Page and line numbers are for Issue 8 draft 2.1 After page 156 line 5406 section 8.1 Environment Variable Definition, add: Implementations may ignore some environment variables at the point of use for security reasons, for example in programs whose real and effective user IDs or real and effective group IDs were not equal at program startup. The behavior shall be as if the implementation obtains the values for these environment variables using secure_getenv() instead of getenv() (see [xref to getenv()]); they shall not be removed from the environment of affected processes and shall be inherited as required by this standard. After page 358 line 12432 section , add: [CX]char *secure_getenv(const char *);[/CX] On page 501 line 17742 section 2.9.1, change: the getenv() function and to: the getenv() and secure_getenv() functions and On page 774 line 26454 section exec, and page 3691 line 127760 section E.1, change: getenv() to: getenv(), secure_getenv() On page 1022 line 35036 section getenv(), change: getenv to: getenv, secure_getenv After page 1022 line 35039 section getenv(), add: [CX]char *secure_getenv(const char *name);[/CX] After page 1022 line 35054 section getenv(), add: [CX]The secure_getenv() function shall be equivalent to getenv(), except that it shall return a null pointer if the calling process does not meet all of the following security criteria: The effective user ID and real user ID of the calling process were equal during program startup. The effective group ID and real group ID of the calling process were equal during program startup. Additional implementation-defined security criteria. [/CX] After page 1022 line 35058 section getenv(), add: [CX]Upon successful completion, secure_getenv() shall return a pointer to a string containing the value for the specified name. If the specified name cannot be found in the environment of the calling process, or the calling process does not meet the security criteria listed in DESCRIPTION, a null pointer shall be returned.[/CX] After page 1790, sched_yield() entry, insert secure_getenv() pointer page to getenv() After page 3457 line 118185 section A.8.1, add: Some historical implementations removed certain environment variables during program startup when security criteria were not met, instead of just ignoring them at the point of use. The standard developers decided not to allow this behavior because if a process drops all privileges and sets its effective user and group IDs to be the same as its real user and group IDs before executing a program or utility, the behavior should be the same as if the process had originally met the security criteria. Bug 0000251: Forbid newline, or even bytes 1 through 31 (inclusive), in filenames OPEN http://austingroupbugs.net/view.php?id=251 This was discussed on the call and will be continued next time Next Steps ---------- There will be no meetings on either May 30 or June 2nd The next calls are on: Mon 2022-06-06 (gettext) Thu 2022-06-09 (general bugs) Note these two will have different dialin details and be by Webex Apologies in advance: Nick Stoughton 2022-06-06 and 2022-06-09 The calls are for 90 minutes Calls are anchored on US time. (8am Pacific) Please check the calendar invites for dial in details. Bugs are at: https://austingroupbugs.net An etherpad is usually up for the meeting, with a URL using the date format as below: https://posix.rhansen.org/p/20xx-mm-dd (For write access this uses The Open Group single sign on, for those individuals with gitlab.opengroup.org accounts. Please contact Andrew if you need to be setup)