Messages in this thread | | | Date | Thu, 14 Nov 1996 22:00:16 -0500 (EST) | From | Elliot Lee <> | Subject | Re: Glitch in sys_chroot() |
| |
On 14 Nov 1996, Aaron M. Ucko wrote:
> > Elliot Lee <sopwith@cuc.edu> writes: > > > > 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. > > > > I don't think the bug is in chroot(8) necessarily (although > > > > POSIX tests don't include chroot AFAIK, the man pages on other systems > > don't specify that the PWD isn't changed (although they DO specify that > > /.. should point to /., a behaviour which Linux follows) therefore there > > is no real standard as to determine what makes it incorrect/correct. > > Which other systems' manpages did you read? I found a few which did > not specify what the new cwd should be, but also several which said > that Linux's behavior was correct. For instance: > > SunOS 4.1.1: "The current working directory is unaffected by this call." > > SunOS 5.4 / Solaris 2.4: "The user's working directory is unaffected > by the chroot() and fchroot() functions." > > IRIX 5.3: "The user's working directory is unaffected by the chroot > system call." > > NetBSD 1.2: "It should be noted that chroot() has no effect on the > process's current directory." > > Any questions?
Beg pardon, you are correct. I read the SunOS & Solaris pages (not thoroughly enough).
I still think that Linux should do the chdir() before the chroot(). If you can provide a reason why - besides "because that's the way it has been done" - I'd say you have a valid point. Until then I remain unconvinced, because of the possible security concerns from lax programming.
In other words, are there any solid reasons other than vague tradition why it shouldn't be done?
Thanks, -- Elliot
http://www.redhat.com/
| |