> Am 22.08.2015 um 15:45 schrieb Brandon Allbery <allbery.b at
gmail.com>:
>
> On Sat, Aug 22, 2015 at 9:32 AM, Johan Hendriks <joh.hendriks at
gmail.com>
> wrote:
>
> chroot is what it says on the tin: once set, the specified directory is
> "/". Every file accessed from that point on MUST be available
from a tree
> in which the specified chroot directory is "/". This includes
symlinks ---
> symlink resolution doesn't get to see outside the specified
"/" any more
> than anything else running in the chroot does, so you cannot simply symlink
> to a file outside the chroot. (Hard links are fine, since they are actually
> by inode number; they just have to be on the same partition.)
I found it?s much easier to have actual chroot?ed ssh users once the users
themselves are in an LDAP-directory.
Also, for doing anything useful on that shell, it turned out you need a some
more devices in /dev than the usual chroot (like a chroot?ed PHP-FPM, that just
needs the dev-set of jail(4)).
And a couple of symlinks.
I?ve done this once for a customer (chroot?ed ssh accounts) and unless this gets
more easier in the future, I?ve made a note to myself to not do that again any
time soon.
I hadn?t thought of just using /rescue (I would nullfs-mount it into your
target-directory, else you?ve got to copy it again every time you run
freebsd-update).
But in my php-fpm chroots, I also need stuff from packages (ImageMagick, most
notably).
I end up nullfs-mounting most of the system (except /sbin directories) into the
various chroots, but I was always looking for a better approach.
It?s all a bit of an hack, with lots of stuff borrowed from ezjail ;-)
The big advantage of using nullfs mounts is that I don?t have to think about
updating the chroots if I update the packages (except /var/run/ld-elf*).
Thinking about this: now that we have pkg - would pkg -c (chroot) also create
the SQLite DB inside the chroot?
Regards,
Rainer