[Solved] Perl with logger inside Jail

Discussion in 'Installation/Configuration' started by Nap, Dec 10, 2020.

  1. Nap

    Nap Member

    In the process of setting up a git repository using gitolite on my server and following the instructions at https://gitolite.com/gitolite/fool_proof_setup#fool-proof-step-by-step-install-and-setup, I managed to break the jail of the virtual host which I'm intending to use.

    During the gitolite install, I found I needed to add Perl to the jail and performed `jk_init -v -f <rootJailFolder> perl`. However, this did not fix the install script and I needed to add some additional libraries. My modified [perl] definition, which fixed the issue I was having at this point, is:

    comment = the perl interpreter and libraries
    executables = /usr/bin/perl
    directories = /usr/lib/perl, /usr/lib/perl5, /usr/share/perl, /usr/share/perl5, /usr/lib/x86_64-linux-gnu/perl, /usr/lib/x86_64-linux-gnu/perl5, /usr/lib/x86_64-linux-gnu/perl-base

    After doing this, I came across another problem where the install script needed 'logger', but was unable to find it, so I added `regularfiles = /usr/bin/logger` to the [perl] definition, but used jk_cp to actually copy it into the jail (which carried with it a lot of dependencies, though it appears that some may have been missed).

    On the next run, instead of getting Perl error messages, I received a SEG FAULT.

    Subsequent to the SEG FAULT, I have not been able to `chroot` into the jail and receive a SEG FAULT when I try.

    I suspect that either:
    some required files were not copied across when I added `/usr/bin/logger`
    some environment variable definition is missing, or
    there is a folder either missing or has the wrong permissions
    which are causing the SEG FAULT.

    As I'm only trivially familiar with Perl, I'm not quite sure where to look and what to do next. I've tried using DIFF to compare a still working jail (though one without Perl) with the broken jail, but I can't see anything significant yet. I have also compared `strace chroot <rootJailFolder>` on a working jail with the one that's broken, but again there doesn't seem anything obvious.

    Whilst reading about using `logger` in a chrooted jail, I see that the normal use case for this is based on a need to log SFTP transactions. In my case, it's the gitolite scripts that need it, so I'm not certain how the information I'm seeing is relevant to what I need (i.e. which parts would I need and which I don't).

    I'm wondering if anyone else has had a similar issue and knows how to fix it? Or, I'm wondering if anyone has suggestions on how to isolate the problem.

    (I am able to provide further information/logs/etc. if needed.)
  2. Jesse Norell

    Jesse Norell ISPConfig Developer Staff Member ISPConfig Developer

    Try ltrace to try to determine what is going on when it receives the segv signal.
  3. Nap

    Nap Member

    Thanks. I did that and got the following result:

    __libc_start_main(0x401990, 2, 0x7fffe9fc7018, 0x405c50 <unfinished ...>
    strrchr("chroot", '/')                                                                                                                                                                                                     = nil
    setlocale(LC_ALL, "")                                                                                                                                                                                                      = "en_US.UTF-8"
    bindtextdomain("coreutils", "/usr/share/locale")                                                                                                                                                                           = "/usr/share/locale"
    textdomain("coreutils")                                                                                                                                                                                                    = "coreutils"
    __cxa_atexit(0x402820, 0, 0, 0x736c6974756572)                                                                                                                                                                             = 0
    getopt_long(2, 0x7fffe9fc7018, "+", 0x406280, nil)                                                                                                                                                                         = -1
    canonicalize_file_name(0x7fffe9fc86f1, 0x405e05, 0x7f1589ea7ea0, 0)                                                                                                                                                        = 0x2233030
    free(0x2233030)                                                                                                                                                                                                            = <void>
    chroot(0x7fffe9fc86f1, 0xffffffff, 0, 0x2233030)                                                                                                                                                                           = 0
    chdir("/")                                                                                                                                                                                                                 = 0
    getenv("SHELL")                                                                                                                                                                                                            = "/bin/bash"
    free(0)                                                                                                                                                                                                                    = <void>
    free(0)                                                                                                                                                                                                                    = <void>
    execvp(0x7fffe9fc873e, 0x7fffe9fc7018, 0x405ddc, 10 <no return ...>
    --- Called exec() ---
    --- SIGSEGV (Segmentation fault) ---
    +++ killed by SIGSEGV +++
    Now to understand it.
    When I did the same for the working jail, the trace is essentially identical until the last four lines. In the working case, instead of SIGSEGV, it has:

    execvp(0x7fff63cc673e, 0x7fff63cc51e8, 0x405ddc, 10 <no return ...>
    --- Called exec() ---
    __libc_start_main(0x41eab0, 2, 0x7ffca4182a78, 0x4b5250 <unfinished ...>
    __sigsetjmp(0x6fe360, 0, 0x7ffca4182a90, 0)                                       = 0
    with a lot of subsequent activity.

    What is interesting if that the `execvp` call is to a different location. So, it looks like it's failing in libc?
    Last edited: Dec 10, 2020
  4. Nap

    Nap Member

    I've looked at the libc.so.6 files in each of the jails (working and not working) and they are significantly different.
    In the working jail it's a symlink to livc-2.19.so but in the broken jail it's a symlink to libc-2.23.so.

    Seems to me I may need to update all the files I have in the broken jail since I did the jk_init and jk_cp using more recent versions.
    How can a jail be updated? Is there something similar in Jailkit to `apt-get upgrade`?
  5. Jesse Norell

    Jesse Norell ISPConfig Developer Staff Member ISPConfig Developer

    Yeah, I'd guess just bad libraries is all. The easiest way is update to 3.2.1 and use the jailkit management features, which can delete the jail entirely and set custom apps/sections to be added to the individual jails.
  6. Nap

    Nap Member

    Thanks Jesse.

    What happened is that I created the jail a long time ago, under Ubuntu 14 in fact. But when I used jk_init to add Perl, it was pulling files from the current OS, which is Ubuntu 16. So, of course there were conflicts. I've now updated the whole jail, and everything is working.

Share This Page