That's an interesting tidbit. Though, with the last paragraph, I wonder how canonical paths worked when you have directories "above" the root.

Very early versions of Unix didn't enforce a hierarchical file system---it was, in fact, a directed graph (not only could you have multiple hardlinks to files, but multiple hardlinks to directories!). (information from "Unix Implementation", Bell System Technical Journal, July-August 1978). So things back then were a lot less ... structured.

I suspect that the answer is 'badly'. V7's chroot() seems to be more than a little bit of a fast hack, one that was good enough for some things but not at all comprehensive or problem free.

(There are PDP-11 emulators and V7 disk images available through tuhs.org, so intrepid people who want to find out for themselves can actually try this out on a live V7 system.)

I think that chroot predates anything in kernel that would care about canonical paths. OS X manpage (first google hit for "getcwd history") claims that "The getwd() function appeared in 4.0BSD.", which is to this day essentially the only syscall that returns path name.

You don't. A correct `chroot()` implementation shouldn't let you access paths that aren't below the new `/`.

That is indeed the modern behaviour of chroot. It is not clear that the "original implementation" shown in the article shares that property, though.

EDIT: That's not to say it doesn't prevent that behaviour. If the usual code to prevent you ..ing above the root checks against u.u_rdir instead of /, it might well work as modern implementations do.

My recollection of chroot in the late '90s is that it didn't provide a jail.

Must of been OS dependent. When I was doing bootp stuff in the mid '90s the whole point of chroot was the jail.

You could define the canonical path for such paths to begin with /../

One of the old security scanners (SATAN/SAINT or COPS maybe?) would test and report if your chroot was vulnerable to `cd ..`.

That's why for a while people would use fsdb to point .. to . instead.

chroot was always intended to allow running processes picky about their system environment.