On Thu, Jun 26, 2014 at 04:47:04PM +0200, Denys Vlasenko wrote:
> On Thu, Jun 26, 2014 at 1:37 PM, Morten Kvistgaard
> <m...@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
_______________________________________________
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
