Open all files with O_NOCTTY

[l0kod]

To avoid inconsistent behavior, especially for daemons, the libstd should (by default) use O_NOCTTY for all open files.
The OpenOptions builder could be extended to switch this flag off.

cc #24306

[alexcrichton]

This seems like a somewhat obscure flag to be passing by default, but are you aware of any other libraries which do this by default?

[l0kod]

All software dealing with TTY (i.e. TUI tools, startup daemons…) does or should handle controlling TTY, including the libraries they could use (e.g. OpenSSL, ). Cf. Debian code for more examples.

Anyway, it seems a sane default option needed for deterministic behavior. Not using O_NOCTTY by default means doing something you don't ask for: getting a controlling TTY.

If a daemon, which does/must not have a controlling TTY, open a file or file descriptor form an insecure location, it could get an unwanted controlling TTY. It need to take care of all open(2), especially from every used Rust libraries.

This could also have an impact on sandboxing (e.g. with gaol) or cause unattended/inconsistent behavior because of signal handling.

cc @pcwalton
cc #11203

[l0kod]

cc #26470

[steveklabnik]

Triage: I am not aware of any changes here. @rust-lang/libs is this something we still want to consider?

[brson]

The flag does seem appropriate to use by default from reading the docs: "If set and path identifies a terminal device, open() shall not cause the terminal device to become the controlling terminal for the process." That implies to me that std is unsuitable for opening TTY devices.

[alexcrichton]

This was discussed during libs triage today and the decision was to close. This has been open quite awhile and looking back there doesn't seem to be strong motivation listed here for why we should pass this flag. If this is still an issue though please feel free to open a new issue!

[l0kod]

The documentation should mention, as says @brson, that the standard library is unsuitable for opening a TTY device.