0001851: FD_CLOFORK should not be preserved across exec

Austin Group Defect Tracker

Aardvark Mark IV

Viewing Issue Simple Details [ Jump to Notes ]

[ Issue History ] [ Print ]

Category

Severity

Type

Date Submitted

Last Update

0001851

[1003.1(2024)/Issue8] System Interfaces

Objection

Error

2024-08-11 02:11

2024-08-15 15:39

Reporter

philip-guenther

View Status

public

Assigned To

Priority

normal

Resolution

Open

Status

New

Name

Philip Guenther

Organization

OpenBSD

User Reference

Section

exec

Page Number

867

Line Number

29528-29530

Interp Status

---

Final Accepted Text

Summary

0001851: FD_CLOFORK should not be preserved across exec

Description

Given the documented use-cases and rationale for close-on-fork in addressing a race condition in multi-threaded processes that mix fork() and file-descriptor creation, the need for the flag to be set would appear to end at the time of a successful exec, when all the other threads in the process are terminated. Since the appropriateness of the flag is specific to the internal design of a program, it seems it should be limited to the program that set it and be cleared by exec.

Having it set when not expected is going to cause program misbehavior. For example, a utility which calls fork() and then opens a file descriptor in the child will probably have unexpected behavior if it's invoked with FD_CLOFORK set on any of fds 0, 1, or 2 as stdin, stdout, or stderr ends up associated with an expected file/socket/whatever. Considering POSIX's evolution on the state of fds 0, 1, and 2 after exec**, reintroducing this issue for programs that fork seems like a regression. This is obviously even more concerning in the context of setuid/setgid programs.

As an additional argument, consider that since the standard doesn't say that invoking a standard utility with FD_CLOFORK set on any the fds that the utility may use is an non-compliant invocation environment (like how completely clearing the environment is), compliant implementations of standard utilities must work as specified in that case. For utilities that fork and use inheritied-fds in the child, this renders implementations that were compliant on an Issue 7 system non-compliant on an Issue 8 system if they would have to clear FD_CLOFORK to operate correctly.

The question of whether FD_CLOFORK should be preserved across exec appears to have been a lacuna in the original request, simply unconsidered there. While the specified behavior is simple to explain and implement, discussions with other OpenBSD systems programmers about what will need to change in the system when FD_CLOFORK is implemented has convinced us that it's unnecessary for the described goal, error prone, and will almost certainly result in security issues in existing programs if implemented as specified.

** Issue 5 and earlier: nothing special permitted.
Issue 6: if 0, 1, or 2 would be closed after exec of setuid or setgid program, the system may open something on the would-be-closed fds.
Issue 7: like issue 6, but for all programs, not just setuid/setgid ones

Desired Action

Replace this sentence:

For those file descriptors that remain open, all attributes of the open file description shall remain unchanged and the FD_CLOFORK file descriptor flag, if set, shall remain set.

With something equivalent to:

For those file descriptors that remain open, all attributes of the open file description shall remain unchanged except that the FD_CLOFORK file descriptor flag, if set, shall be cleared.

If it cannot be changed in one jump in a TC, then at least render it unspecified whether FD_CLOFORK is preserved by exec, and if at all possible also require it to be cleared when a setuid/setgid program is invoked.

Issue History
Date Modified	Username	Field	Change
2024-08-11 02:11	philip-guenther	New Issue
2024-08-11 02:11	philip-guenther	Name	=> Philip Guenther
2024-08-11 02:11	philip-guenther	Organization	=> OpenBSD
2024-08-11 02:11	philip-guenther	Section	=> exec
2024-08-11 02:11	philip-guenther	Page Number	=> 867
2024-08-11 02:11	philip-guenther	Line Number	=> 29528-29530
2024-08-15 15:39	geoffclare	Relationship added	related to 0001318