Some implementations permit opening FIFOs with O_RDWR. Since
FIFOs could be implemented in other ways, and since two file
descriptors can be used to the same effect, this possibility is
left as undefined.
See getgroups(3p) about the group of a newly created file.
The use of open() to create a regular file is preferable to the
use of creat(), because the latter is redundant and included only
for historical reasons.
The use of the O_TRUNC flag on FIFOs and directories (pipes
cannot be open()-ed) must be permissible without unexpected side-
effects (for example, creat() on a FIFO must not remove data).
Since terminal special files might have type-ahead data stored in
the buffer, O_TRUNC should not affect their content, particularly
if a program that normally opens a regular file should open the
current controlling terminal instead. Other file types,
particularly implementation-defined ones, are left
implementation-defined.
POSIX.1‐2008 permits [EACCES] to be returned for conditions other
than those explicitly listed.
The O_NOCTTY flag was added to allow applications to avoid
unintentionally acquiring a controlling terminal as a side-effect
of opening a terminal file. This volume of POSIX.1‐2017 does not
specify how a controlling terminal is acquired, but it allows an
implementation to provide this on open() if the O_NOCTTY flag is
not set and other conditions specified in the Base Definitions
volume of POSIX.1‐2017, Chapter 11, General Terminal Interface
are met.
In historical implementations the value of O_RDONLY is zero.
Because of that, it is not possible to detect the presence of
O_RDONLY and another option. Future implementations should encode
O_RDONLY and O_WRONLY as bit flags so that:
O_RDONLY | O_WRONLY == O_RDWR
O_EXEC and O_SEARCH are specified as two of the five file access
modes. Since O_EXEC does not apply to directories, and O_SEARCH
only applies to directories, their values need not be distinct.
Since O_RDONLY has historically had the value zero,
implementations are not able to distinguish between O_SEARCH and
O_SEARCH | O_RDONLY, and similarly for O_EXEC.
In general, the open() function follows the symbolic link if path
names a symbolic link. However, the open() function, when called
with O_CREAT and O_EXCL, is required to fail with [EEXIST] if
path names an existing symbolic link, even if the symbolic link
refers to a nonexistent file. This behavior is required so that
privileged applications can create a new file in a known location
without the possibility that a symbolic link might cause the file
to be created in a different location.
For example, a privileged application that must create a file
with a predictable name in a user-writable directory, such as the
user's home directory, could be compromised if the user creates a
symbolic link with that name that refers to a nonexistent file in
a system directory. If the user can influence the contents of a
file, the user could compromise the system by creating a new
system configuration or spool file that would then be interpreted
by the system. The test for a symbolic link which refers to a
nonexisting file must be atomic with the creation of a new file.
In addition, the open() function refuses to open non-directories
if the O_DIRECTORY flag is set. This avoids race conditions
whereby a user might compromise the system by substituting a hard
link to a sensitive file (e.g., a device or a FIFO) while a
privileged application is running, where opening a file even for
read access might have undesirable side-effects.
In addition, the open() function does not follow symbolic links
if the O_NOFOLLOW flag is set. This avoids race conditions
whereby a user might compromise the system by substituting a
symbolic link to a sensitive file (e.g., a device) while a
privileged application is running, where opening a file even for
read access might have undesirable side-effects.
The POSIX.1‐1990 standard required that the group ID of a newly
created file be set to the group ID of its parent directory or to
the effective group ID of the creating process. FIPS 151‐2
required that implementations provide a way to have the group ID
be set to the group ID of the containing directory, but did not
prohibit implementations also supporting a way to set the group
ID to the effective group ID of the creating process. Conforming
applications should not assume which group ID will be used. If it
matters, an application can use chown() to set the group ID after
the file is created, or determine under what conditions the
implementation will set the desired group ID.
The purpose of the openat() function is to enable opening files
in directories other than the current working directory without
exposure to race conditions. Any part of the path of a file could
be changed in parallel to a call to open(), resulting in
unspecified behavior. By opening a file descriptor for the target
directory and using the openat() function it can be guaranteed
that the opened file is located relative to the desired
directory. Some implementations use the openat() function for
other purposes as well. In some cases, if the oflag parameter has
the O_XATTR bit set, the returned file descriptor provides access
to extended attributes. This functionality is not standardized
here.
