xbd_chap03.html

IEEE 1003.1-2003, Single Unix Specification v3

</ul>

<h5><a name="tag_01_03_00_41"></a>Orphaned Process Group</h5>

<p>Historical implementations have a concept of an orphaned process, which is a process whose parent process has exited. When job
control is in use, it is necessary to prevent processes from being stopped in response to interactions with the terminal after they
no longer are controlled by a job control-cognizant program. Because signals generated by the terminal are sent to a process group
and not to individual processes, and because a signal may be provoked by a process that is not orphaned, but sent to another
process that is orphaned, it is necessary to define an orphaned process group. The definition assumes that a process group will be
manipulated as a group and that the job control-cognizant process controlling the group is outside of the group and is the parent
of at least one process in the group (so that state changes may be reported via <a href=
"../functions/waitpid.html"><i>waitpid</i>()</a>). Therefore, a group is considered to be controlled as long as at least one
process in the group has a parent that is outside of the process group, but within the session.</p>

<p>This definition of orphaned process groups ensures that a session leader's process group is always considered to be orphaned,
and thus it is prevented from stopping in response to terminal signals.</p>

<h5><a name="tag_01_03_00_42"></a>Page</h5>

<p>The term &quot;page&quot; is defined to support the description of the behavior of memory mapping for shared memory and memory mapped
files, and the description of the behavior of process memory locking. It is not intended to imply that shared memory/file mapping
and memory locking are applicable only to &quot;paged&quot; architectures. For the purposes of IEEE&nbsp;Std&nbsp;1003.1-2001, whatever the
granularity on which an architecture supports mapping or locking, this is considered to be a &quot;page&quot; . If an architecture cannot
support the memory mapping or locking functions specified by IEEE&nbsp;Std&nbsp;1003.1-2001 on any granularity, then these options
will not be implemented on the architecture.</p>

<h5><a name="tag_01_03_00_43"></a>Passwd File*</h5>

<p>Implementation-defined; see <a href="#tag_01_03_00_63">User Database</a> .</p>

<h5><a name="tag_01_03_00_44"></a>Parent Directory</h5>

<p>There may be more than one directory entry pointing to a given directory in some implementations. The wording here identifies
that exactly one of those is the parent directory. In pathname resolution, dot-dot is identified as the way that the unique
directory is identified. (That is, the parent directory is the one to which dot-dot points.) In the case of a remote file system,
if the same file system is mounted several times, it would appear as if they were distinct file systems (with interesting
synchronization properties).</p>

<h5><a name="tag_01_03_00_45"></a>Pipe</h5>

<p>It proved convenient to define a pipe as a special case of a FIFO, even though historically the latter was not introduced until
System&nbsp;III and does not exist at all in 4.3 BSD.</p>

<h5><a name="tag_01_03_00_46"></a>Portable Filename Character Set</h5>

<p>The encoding of this character set is not specified-specifically, ASCII is not required. But the implementation must provide a
unique character code for each of the printable graphics specified by POSIX.1; see also <a href=
"xbd_chap04.html#tag_01_04_06"><i>Filenames</i></a> .</p>

<p>Situations where characters beyond the portable filename character set (or historically ASCII or the ISO/IEC&nbsp;646:1991
standard) would be used (in a context where the portable filename character set or the ISO/IEC&nbsp;646:1991 standard is required
by POSIX.1) are expected to be common. Although such a situation renders the use technically non-compliant, mutual agreement among
the users of an extended character set will make such use portable between those users. Such a mutual agreement could be formalized
as an optional extension to POSIX.1. (Making it required would eliminate too many possible systems, as even those systems using the
ISO/IEC&nbsp;646:1991 standard as a base character set extend their character sets for Western Europe and the rest of the world in
different ways.)</p>

<p>Nothing in POSIX.1 is intended to preclude the use of extended characters where interchange is not required or where mutual
agreement is obtained. It has been suggested that in several places &quot;should&quot; be used instead of &quot;shall&quot;. Because (in the worst
case) use of any character beyond the portable filename character set would render the program or data not portable to all possible
systems, no extensions are permitted in this context.</p>

<h5><a name="tag_01_03_00_47"></a>Regular File</h5>

<p>POSIX.1 does not intend to preclude the addition of structuring data (for example, record lengths) in the file, as long as such
data is not visible to an application that uses the features described in POSIX.1.</p>

<h5><a name="tag_01_03_00_48"></a>Root Directory</h5>

<p>This definition permits the operation of <i>chroot</i>(), even though that function is not in POSIX.1; see also <a href=
"xbd_chap04.html#tag_01_04_05"><i>File Hierarchy</i></a> .</p>

<h5><a name="tag_01_03_00_49"></a>Root File System*</h5>

<p>Implementation-defined.</p>

<h5><a name="tag_01_03_00_50"></a>Root of a File System*</h5>

<p>Implementation-defined; see <a href="#tag_01_03_00_35">Mount Point*</a> .</p>

<h5><a name="tag_01_03_00_51"></a>Signal</h5>

<p>The definition implies a double meaning for the term. Although a signal is an event, common usage implies that a signal is an
identifier of the class of event.</p>

<h5><a name="tag_01_03_00_52"></a>Superuser*</h5>

<p>This concept, with great historical significance to UNIX system users, has been replaced with the notion of appropriate
privileges.</p>

<h5><a name="tag_01_03_00_53"></a>Supplementary Group ID</h5>

<p>The POSIX.1-1990 standard is inconsistent in its treatment of supplementary groups. The definition of supplementary group ID
explicitly permits the effective group ID to be included in the set, but wording in the description of the <a href=
"../functions/setuid.html"><i>setuid</i>()</a> and <a href="../functions/setgid.html"><i>setgid</i>()</a> functions states: &quot;Any
supplementary group IDs of the calling process remain unchanged by these function calls&quot;. In the case of <a href=
"../functions/setgid.html"><i>setgid</i>()</a> this contradicts that definition. In addition, some felt that the unspecified
behavior in the definition of supplementary group IDs adds unnecessary portability problems. The standard developers considered
several solutions to this problem:</p>

<ol>
<li>
<p>Reword the description of <a href="../functions/setgid.html"><i>setgid</i>()</a> to permit it to change the supplementary group
IDs to reflect the new effective group ID. A problem with this is that it adds more &quot;may''s to the wording and does not address
the portability problems of this optional behavior.</p>
</li>

<li>
<p>Mandate the inclusion of the effective group ID in the supplementary set (giving {NGROUPS_MAX} a minimum value of 1). This is
the behavior of 4.4 BSD. In that system, the effective group ID is the first element of the array of supplementary group IDs (there
is no separate copy stored, and changes to the effective group ID are made only in the supplementary group set). By convention, the
initial value of the effective group ID is duplicated elsewhere in the array so that the initial value is not lost when executing a
set-group-ID program.</p>
</li>

<li>
<p>Change the definition of supplementary group ID to exclude the effective group ID and specify that the effective group ID does
not change the set of supplementary group IDs. This is the behavior of 4.2 BSD, 4.3 BSD, and System&nbsp;V Release 4.</p>
</li>

<li>
<p>Change the definition of supplementary group ID to exclude the effective group ID, and require that <a href=
"../functions/getgroups.html"><i>getgroups</i>()</a> return the union of the effective group ID and the supplementary group
IDs.</p>
</li>

<li>
<p>Change the definition of {NGROUPS_MAX} to be one more than the number of supplementary group IDs, so it continues to be the
number of values returned by <a href="../functions/getgroups.html"><i>getgroups</i>()</a> and existing applications continue to
work. This alternative is effectively the same as the second (and might actually have the same implementation).</p>
</li>
</ol>

<p>The standard developers decided to permit either 2 or 3. The effective group ID is orthogonal to the set of supplementary group
IDs, and it is implementation-defined whether <a href="../functions/getgroups.html"><i>getgroups</i>()</a> returns this. If the
effective group ID is returned with the set of supplementary group IDs, then all changes to the effective group ID affect the
supplementary group set returned by <a href="../functions/getgroups.html"><i>getgroups</i>()</a>. It is permissible to eliminate
duplicates from the list returned by <a href="../functions/getgroups.html"><i>getgroups</i>()</a>. However, if a group ID is
contained in the set of supplementary group IDs, setting the group ID to that value and then to a different value should not remove
that value from the supplementary group IDs.</p>

<p>The definition of supplementary group IDs has been changed to not include the effective group ID. This simplifies permanent
rationale and makes the relevant functions easier to understand. The <a href="../functions/getgroups.html"><i>getgroups</i>()</a>
function has been modified so that it can, on an implementation-defined basis, return the effective group ID. By making this
change, functions that modify the effective group ID do not need to discuss adding to the supplementary group list; the only view
into the supplementary group list that the application writer has is through the <a href=
"../functions/getgroups.html"><i>getgroups</i>()</a> function.</p>

<h5><a name="tag_01_03_00_54"></a>Symbolic Link</h5>

<p>Many implementations associate no attributes, including ownership with symbolic links. Security experts encouraged consideration
for defining these attributes as optional. Consideration was given to changing <a href="../functions/utime.html"><i>utime</i>()</a>
to allow modification of the times for a symbolic link, or as an alternative adding an <i>lutime</i>() interface. Modifications to
<a href="../functions/chown.html"><i>chown</i>()</a> were also considered: allow changing symbolic link ownership or alternatively
adding <a href="../functions/lchown.html"><i>lchown</i>()</a>. As a result of alignment with the Single UNIX Specification, the <a
href="../functions/lchown.html"><i>lchown</i>()</a> function is included as part of the XSI extension and XSI-conformant systems
may support an owner and a group associated with a symbolic link. There was no consensus to define further attributes for symbolic
links, and for systems not supporting the XSI extension only the file type bits in the <i>st_mode</i> member and the <i>st_size</i>
member of the <b>stat</b> structure are required to be applicable to symbolic links.</p>

<p>Historical implementations were followed when determining which interfaces should apply to symbolic links. Interfaces that
historically followed symbolic links include <a href="../functions/chmod.html"><i>chmod</i>()</a>, <a href=
"../functions/link.html"><i>link</i>()</a>, and <a href="../functions/utime.html"><i>utime</i>()</a>. Interfaces that historically
do not follow symbolic links include <a href="../functions/chown.html"><i>chown</i>()</a>, <a href=
"../functions/lstat.html"><i>lstat</i>()</a>, <a href="../functions/readlink.html"><i>readlink</i>()</a>, <a href=
"../functions/rename.html"><i>rename</i>()</a>, <a href="../functions/remove.html"><i>remove</i>()</a>, <a href=
"../functions/rmdir.html"><i>rmdir</i>()</a>, and <a href="../functions/unlink.html"><i>unlink</i>()</a>.
IEEE&nbsp;Std&nbsp;1003.1-2001 deviates from historical practice only in the case of <a href=
"../functions/chown.html"><i>chown</i>()</a>. Because there is no requirement for systems not supporting the XSI extension that
there is an association of ownership with symbolic links, there was no interface in the base standard to change ownership. In
addition, other implementations of symbolic links have modified <a href="../functions/chown.html"><i>chown</i>()</a> to follow
symbolic links.</p>

<p>In the case of symbolic links, IEEE&nbsp;Std&nbsp;1003.1-2001 states that a trailing slash is considered to be the final
component of a pathname rather than the pathname component that preceded it. This is the behavior of historical implementations.
For example, for <b>/a/b</b> and <b>/a/b/</b>, if <b>/a/b</b> is a symbolic link to a directory, then <b>/a/b</b> refers to the
symbolic link, and <b>/a/b/</b> is the same as <b>/a/b/.</b>, which is the directory to which the symbolic link points.</p>

<p>For multi-level security purposes, it is possible to have the link read mode govern permission for the <a href=
"../functions/readlink.html"><i>readlink</i>()</a> function. It is also possible that the read permissions of the directory