ftpd authentication [PATCH] ftpd: NOMMU/chroot fix

Rich Felker dalias at libc.org
Thu Jun 26 17:28:54 UTC 2014


On Thu, Jun 26, 2014 at 04:47:04PM +0200, Denys Vlasenko wrote:
> On Thu, Jun 26, 2014 at 1:37 PM, Morten Kvistgaard
> <MK at pch-engineering.dk> wrote:
> >>> ...
> >>> execve("proc/self/exe", ["ftpd", "-l", "/"], [/* 9 vars */]) = -1
> >>> ENOENT (No such file or directory) ...
> >>
> >>This is strange. Any ideas why this fails on your machine?
> >
> > Yes, the fchdir(G.root_fd) is not enough to break the jail. (And it's not just my machine. It's all of our Ubuntu versions and all of our uClinux versions. Which made me assume that it was a general issue.)
> >
> > There's a nice quote, I think: Ref: http://m.oschina.net/blog/113399. (One of the first hits on google. There're prolly better sources.)
> >
> > ===========================================
> >
> >
> > /* Partially break out of the chroot jail by doing an fchdir()
> >      This only partially breaks out of the chroot() jail since whilst
> >      our current working directory is outside the chroot jail, our
> >      root directory is still within it. Thus anything which refers to
> >       "/" will refer to files under the chroot point.
> >  */
> >         if (fchdir(dir_fd)<0) {
> >                 fprintf(stderr, "Failed to fchdir - %s\n",
> >                         strerror(errno));
> >                 exit(1);
> >         }
> 
> The point is, we *do not* refer to "/".
> We exec "proc/self/exe", NOT "/proc/self/exe".
> 
> It does work on my machine.
> 
> How come it doesn't work on your machine?

If proc/self/exe make be relative to the working directory, but
/lib/ld-whatever.so from proc/self/exe's PT_INTERP header is certainly
not relative. This is the cause of the ENOENT.

Rich


More information about the busybox mailing list