Re: Glitch in sys_chroot()

Kai Henningsen (
16 Nov 1996 16:48:00 +0200 (Alan Cox) wrote on 15.11.96 in <>:

> > That's because the bug is in chroot(8), not chroot(2). chroot(2) is
> > supposed to change only the root directory; Linux's behavior is
> > correct.
> Changing chroot(2) for security reasons to the same is a smart move however.

I don't think so. It's not compatible, and furthermore (see below), it's
also a very bad idea.

This is from the "Single Unix Specification" (EX == extension, UX ==
X/Open extension):


3.3.14 chroot()

chroot change root directory (TO BE WITHDRAWN)


EX#include <unistd.h>

int chroot(const char *path);

The path argument points to a pathname naming a directory. The chroot()
function causes the named directory to become the root directory, that is
the starting point for path searches for pathnames beginning with /. The
process working directory is unaffected by chroot().

The process must have appropriate privileges to change the root

The dot-dot entry in the root directory is interpreted to mean the
root directory itself. Thus, dot-dot cannot be used to access files
outside the subtree rooted at the root directory.

Upon successful completion, 0 is returned. Otherwise, -1 is returned and
errno is set to indicate the error. If -1 is returned, no change is made
in the root directory.

The chroot() function will fail if:

[EACCES] Search permission is denied for a component of

[ELOOP] UXToo many symbolic links were encountered in resolving

The length of the path argument exceeds {PATH_MAX} or a pathname
component is longer than {NAME_MAX}.

[ENOENT] A component of path does not name an existing
directory or path is an empty string.

[ENOTDIR] A component of the path name is not a directory.

[EPERM] The effective user ID does not have appropriate

The chroot() function may fail if:

Pathname resolution of a symbolic link produced an intermediate
result whose length exceeds {PATH_MAX}.

There is no portable use that an application could make of this interface.
It is therefore marked TO BE WITHDRAWN.

chdir(), <unistd.h>.

First released in Issue 1.

Derived from Issue 1 of the SVID.

Issue 4
Changes are incorporated as follows:

The interface is marked TO BE WITHDRAWN, as there is no
portable use that an application could make of this interface.

The header <unistd.h> is added to the SYNOPSIS section.

The type of argument path is changed from char * to const
char *.

The APPLICATION USAGE section is added.

The DESCRIPTION section now refers to the process working
directory instead of the user s working directory.

Issue 4, Version 2
The ERRORS section is updated for X/OPEN UNIX conformance as follows:

It states that [ELOOP] will be returned if too many
symbolic links are encountered during pathname resolution.

A second [ENAMETOOLONG] condition is defined that may
report excessive length of an intermediate result of pathname resolution
of a symbolic link.


As to the command, that one already is "withdrawn" and so has no useable


3.3.12 chroot

chroot - change root directory for a command (WITHDRAWN)


EXchroot newroot command

This utility has been withdrawn because there is no portable way to set up
an environment where it is useful and it is usually usable only by
applications with appropriate privileges.

First released in Issue 2.

Issue 3
Functionally equivalent to the entry in Issue 2.

Issue 4
This page has been marked as withdrawn. The intermediate step of
publishing an issue with a TO BE WITHDRAWN marking has been bypassed
intentionally because of the non-portable aspects of this utility.


As for the security aspects, making chroot() do a chdir() will only serve
to create programmers that think that chroot() will do a chdir() on all
machines. This doesn't close security holes, it *opens* them.

MfG Kai