Chroot Cage Folders in Non-SSH Webs

Discussion in 'General' started by t-mug, May 2, 2008.

  1. t-mug

    t-mug New Member


    the passwd line looks like:
    I followed Falkos instructions to compile a new openssh server (only point 2 of the instructions, but nothing more on my Debian Etch, because I was too lazy for zlib compiling and creating the folders in /home/chroot/) and I set the ISPconfig 2.2.23 value to $go_info["server"]["ssh_chroot"] = 1; as necessary.

    All seems to work correctly, but all new webs get the cage folders like /usr, /etc, /bin. /lib, /var copied to /var/www/web27_grrr.

    What's my mistake? Or is this intended?
    Thanks for the help.
  2. falko

    falko Super Moderator ISPConfig Developer

    That's the correct behaviour. The /home/chroot from the tutorial is just an example; ISPConfig chroots the users to the web directory they belong to.
  3. t-mug

    t-mug New Member

    Sorry. my question was not clear enough. Another try: if I create a new web then the bin, usr, etc, var folders are copied to the webs root, although SSH is not and was never enabled. How can I avoid this?
  4. falko

    falko Super Moderator ISPConfig Developer

    I think you'd have to modify the ISPConfig sources.
  5. t-mug

    t-mug New Member

    There are 2 functions inside /root/ispconfig/scripts/lib/config.lib.php: user_insert() and user_update() which, at their very end, call the script for creating the chroot folders:
    if($go_info["server"]["ssh_chroot"]) {
    exec("/root/ispconfig/scripts/shell/ $user_username");
    and indeed this is called for every user when ssh_chroot for the server is enabled, regardless if the web or even the user has chroot access. This is consuming customers webspace (consider mounts of user accounts) and is irritating also.
    Changing these lines (for ISPconfig 2.2.23 at line number 767 and 941 of config.lib.php) to:
    if($go_info["server"]["ssh_chroot"] == && $user["user_shell"] && $web["web_shell"]) {
    exec("/root/ispconfig/scripts/shell/ $user_username");
    works as expected: no SSH folders will be created on new webs or users with non-checked SSH.

    Falko, do you think there is sth. missing in this solution that could make side effects?

    Nevertheless this does not delete the chroot folders for users if SSH in the admin panel is unchecked again, for both the user or the web. The chroot folders will, once enabled, remain.
    Last edited: May 4, 2008
  6. falko

    falko Super Moderator ISPConfig Developer

    I don't think so. :)
  7. t-mug

    t-mug New Member


    This Patch is for the 2.2.28 release.

    Attached Files:

  8. Ovidiu

    Ovidiu Active Member

    I am just wondering why this info:

    is not mentioned anywhere or did I jsut not find it? I was wodnering all the time, how ispconfig knows I employed the chroot how-to :)
  9. Ovidiu

    Ovidiu Active Member

    Oh, I just foudn out my ssh users were no longer chrooted :-(

    it seems one of the apt-get dist-upgrades broke the jail :-(

    I guess it was an update of sshd? Meaning after any sshd upgrade I have to redo the chroot howto? How can I block the sshd from being upgraded? anything else one needs to take care of?
  10. t-mug

    t-mug New Member

    openssh package

    You have to compile your version of openssh by yourself, see:
    and, yes, look again at the tutorial - there is a hint preventing ssh from being updated:
    but I guess, after a dist-upgrade the old "holds" get lost.

    You can test your holded ssh package at any time by:
    Maybe it's a good idea to put generally some system testing in your crontab and getting notified in case your chroot or even other sensible system points got broken. Crontab entries survive dist-upgrades.

    But probably a much easier way to maintain things is to give your semi trusted users a special bash link that is restricted by apparmor.
    Last edited: Dec 12, 2008
  11. Ovidiu

    Ovidiu Active Member

    thx, I must have overlooked the section where we were advised how to put openssh-server on hold.

    If you have further links, to read more about apparmor, feel free to psot here or PM me :)
  12. t-mug

    t-mug New Member


    Nice Intro: Crispin Cowan (the AppArmor project lead) gave an interesting talk at FOSDEM 2006 via (271 MB)

    Other stuff easy to find by SE's.

    Warning! The coop with ISPConfig has to be carfully observed. Tim was warning about using AppArmor all the time. After installation at least bring really all confined services in complained mode (logging only) and please don't play around in production environments. So I can't tell you more, it's still on my TODO list to get this working and diving deeper into using AppArmor together with ISPConfig. I guess, it is one of the most promising ways to really solve all the annoying security problems around mod_python, mod_ruby and, as I hope, PHP without SAFE MODE and without "disable functions".
    Last edited: Dec 15, 2008
  13. Ovidiu

    Ovidiu Active Member

    anyone noticed that after upgrading from debian 4.0 to 5.0 there are some problems with this solution: and as I retried it, the link to the patched openssh serevr are broken.
    is tehre a newer version of this guide available somewhere?
  14. falko

    falko Super Moderator ISPConfig Developer

  15. Ovidiu

    Ovidiu Active Member

    THX :) great news.
    but how do I get rid of the old stuff done during that how to?
    or is it enought if I just allow that package to be updated again by the system?
  16. falko

    falko Super Moderator ISPConfig Developer

    I think I'd install the OpenSSH package from Lenny (version 5.1 or something like that) and then play around with the ChrootDirectory directive a bit. Not sure if anything needs to be undone.

Share This Page