Messages in this thread | | | Date | 16 Nov 1996 16:48:00 +0200 | From | (Kai Henningsen) | Subject | Re: Glitch in sys_chroot() |
| |
alan@lxorguk.ukuu.org.uk (Alan Cox) wrote on 15.11.96 in <m0vOTPq-0005KjC@lightning.swansea.linux.org.uk>:
> > 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()
NAME chroot ù change root directory (TO BE WITHDRAWN)
SYNOPSIS
EX#include <unistd.h>
int chroot(const char *path);
DESCRIPTION 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 directory.
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.
RETURN VALUE 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.
ERRORS The chroot() function will fail if:
[EACCES] Search permission is denied for a component of path.
[ELOOP] UXToo many symbolic links were encountered in resolving path.
[ENAMETOOLONG] 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 privileges.
The chroot() function may fail if:
UX[ENAMETOOLONG] Pathname resolution of a symbolic link produced an intermediate result whose length exceeds {PATH_MAX}.
APPLICATION USAGE There is no portable use that an application could make of this interface. It is therefore marked TO BE WITHDRAWN.
SEE ALSO chdir(), <unistd.h>.
CHANGE HISTORY 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 description:
******************
3.3.12 chroot chroot
NAME chroot - change root directory for a command (WITHDRAWN)
SYNOPSIS
EXchroot newroot command
APPLICATION USAGE 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.
CHANGE HISTORY 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
| |