Re: chrooting daemons
Bruce Perens writes:
> We don't want to have more than one instance of a library in the filesystem
> if that is at all possible. We currently violate this for anonymous FTP,
> which has its own copy of a few system utilities and its own copy of the
> C shared library. I notice that on my system the libraries and binaries in
> the anonymous FTP chroot directory are older than the rest of the system.
If we had a fexec(int fd,..) (exec from file descriptor) system call, a
daemon could open() ls, tar, gzip and friends, chroot and still be able to
run ls when needed. I don't know how dynamic libs would be dealt with,
though. More open files and LD_PRELOADed shared lib overriding exec's to
fexecs? :-)
> The best way to deal with this would be some sort of filesystem hack under
> the chroot-ed directory. What I want is the capability to import some
> files and directories into the chroot filesystem while changing their
> permissions, but I don't want the ".." links of the directories to point out
> of the chroot context, and I don't want the chroot context to be able to
> change what is imported.
>
> There was something called "userfs" that might have let you do this, but
> I don't see it in recent kernels. It could be done with the prof filesystem.
That's "ifs" (http://www.funet.fi/pub/Linux/mirrors/tsx-11/ALPHA/ifs/),
but its from 1994. The author, W. Almesberger is still active.
-Topi
Reply to: