Changes needed for Jailkit chroot jail support

Hey Jamie,

So, for Jailkit support, we need the following things in Virtualmin:

User Creation

Domain creation form

When creating a domain, there needs to be an option to jail the user. If a domain is jailed, it needs to force all users within to be jailed, as well.

There needs to be a dropdown to select which jail configuration to initialize for the user. This can be determined by the sections of /etc/jailkit/jk_init.ini

You can get the list of jails using the Example of that in delete_jail.cgi. e.g.:

# Load the jk_init.ini into a Config::IniFiles object
my $jk_init_ini = get_jk_init_ini();
# Get an array of the sections (jail definitions)
my @sections = $jk_init_ini->Sections();

Each section in the config file applies to a jail configuration (the files to include in the jail). The object also provides access to the parameters for each option within the, if you needed to be able to display the comment (which usually describes the jail), that'd be available via a function like this: "$jk_init_ini->val( $section, 'comment' );"

During the creation

Once a user has been created, they need to have their jail initialized, and their shell in /etc/passwd switched to include the jail magic bits.

To initialize their jail, run jk_init:

# jk_init -j jail section

Where "jail" is the path to the jail. This should be something like /home/chroot/domainname or /home/jail/domainname (probably should be configurable). jk_init will create the directory and populate it.

And, "section" is the section from the jk_init.ini file to use (the jail configuration ID, like "perl" or "limitedshell". Users can define their own jail configurations in the Jailkit Webmin module which I'll roll into the repos at the same time (could also include in Webmin, though it depends on Config::IniFiles).

Set the user home path and shell

The following must be done manually (well, by Virtualmin). The jk_jailuser command which normally sets up the user to be jailed does so by moving the home directory into the jail. We want to bind mount the home, rather than move the home into the jail, as we need the rest of the system to be able to find the home in /home/domainname...for web services, for mail delivery, etc.

The user entry in /etc/passwd needs two changes from the usual:

The shell needs to be set to jk_chrootsh

And the home directory needs to be set to a weird format, which includes both the chroot path and the home directory path within the chroot. e.g.:


This is a magic format which the jk_chrootsh knows what to do with. The /home/chroot/domainname is the jail created in the previous step, and the /home/domainname is the actual home directory (which will be bind-mounted inside the chroot).

Add a bind mount for the users home

The jail will not contain the user home directory, which kinda defeats the purpose of having a shell login. So, we need to use a bind mount to make it available for the user.

The simplest form of this is adding this to fstab:

/home/domainname  /home/chroot/domainname/home/domainname        none    bind    0 0

On a system with a lot of users, this will lead to a lot of bind mounts, but I can't find any reason for this to be a problem. There are no hard limits imposed by Linux on bind mounts. Docker and some other container systems use bind mounts heavily and with hundreds or thousands of them, so I think we're safe. It might be worth thinking about a way to avoid filling up the fstab with these bind mounts, but I can't think of a good way to do it (the fstab.d feature we talked about in the past never made it to widespread usage and development stopped).

I believe we should put the domain email boxes into the same bind mounted home, so we only need a bind mount per domain, rather than per-user. This means mailbox users with a shell will not be jailed into their home but into the home of their domain, but mailbox users don't need a shell if they aren't trusted. So no big deal, there.

Install Wizard

If the server is going to use jails, it has to call procmail via the jk_procmailwrapper rather than our wrapper. I think this has to be system-wide? So, it'll make it impossible for any domain-level spam/AV configuration for any domain if jails are turned on for any user (right?). I guess we could also modify the jk_procmail_wrapper to do what ours does for users that aren't jailed...but, I've never been very comfortable with it, anyway, and I think it's probably fine to give up per-domain settings.

So, that needs to be in the install wizard. Something along the lines of "Do you want to use chroot jail features for some or all of your users? Enabling this feature for any user will disable per-domain spam/AV features for all users. Per-user spam/AV configuration will still function normally."

You understand the procmail stuff in Virtualmin far better than I do, so you may see a way to not make this all or nothing.

Docs for that are here:

Other Stuff

We probably need UI support for updating files in all configured jails after package updates and such. My module only handles configuration of jail sections in jk_init.ini right now. But, I can add some additional support for keeping up with what jails exist, updating them, etc. We'll need to call chroot support beta for the next couple of months, until we've sorted out all of the intricacies of this.

Also, we need to sort out running cgi and php within a chroot. For the short term, I think PHP-FPM supports chroot out of the box, so we just need to configure it. For CGI, we probably just need to make it possible to disable CGI, and possibly disable by default for chrooted users. It'll all Just Work, if we leave it as-is, but it will provide an easy vector for breaking chroot, since a user could trivially install a web shell which would be unjailed.

Oh, yeah, my Jailkit Webmin module is here:

Let me know if you need additional functionality from it for Virtualmin. I'll poke at adding some of the other stuff I mentioned, but may wait until we release V6 and then work on new features based on user feedback and requests. Just getting auto-jailing out the door is probably the minimum viable product, and then we'll refine from there.

The jailkit package is available in our bleed repo here, as well:

I may need to add a more functional jail configuration to jk_init.ini, as all of them look pretty anemic by default, and I don't want users to feel compelled to put a shell together before they can even use this feature. I tried getting some feedback in the forums, but nobody has poked at it.

Needs review


Ok, I'll work on adding this. It looks like a fairly complex amount of work though, so it might take a while.

Should the module be part of Webmin core? Also, will the packages be available for other distros?

Joe's picture
Submitted by Joe on Wed, 02/08/2017 - 20:22 Pro Licensee

Yeah, I thought it would be simple than it is; the complexity ballooned out as I realized how many pieces get touched when you start jailing users, and how many trivial ways there are to escape a jail, if all those pieces don't change.

Jailkit packages will be available for all the distros we support in Virtualmin at time of release.

The Jailkit module could be in Webmin or it can be distributed via the Virtualmin repos. I lean toward not adding more to Webmin core...I'd rather Webmin get smaller over time, with a thriving module ecosystem. Though every module is small, it leads to a huge bunch of menu items, mostly of things any given user and system doesn't need. So, maybe let's just package it, and also make it available via the module search (I dunno how to do that).

If you're busy and you want me to tackle some of this, I can probably do some of the Virtualmin-level stuff. I may attribute you with super powers too often, and assume things are much easier for you than they are for me. ;-)

So I'm very close to getting this all working! One open question though - can you customize the jk_init.ini config file in the Jailkit RPM we distribute to include a section for PHP files?

Ideally it would contain :

comment = modules and config files for PHP
paths = /etc/php.ini /etc/php.d /usr/lib64/php
Ovidiu's picture
Submitted by Ovidiu on Sun, 05/21/2017 - 11:19

Just commenting to get notifications, I didn't see a way to do that without commenting.

I will subscribe to this node for updates. Thank you for your work.

Is it a documentation available for using this feature? As I did testing by myself:

-Virtualmin -> Administration Option -> Edit Owner Limits -> Other restrictions Chroot jail domain Unix user? = Yes

  • install jailkit package (in Debian apt-get install jailkit)

It is working great but people should be very careful changing [Chroot jail domain Unix user] option to No. They will loose all files in /home/user_name.

I appreciate if I can get more information about how this implementation is working in Virtualmin.

Joe's picture
Submitted by Joe on Sun, 10/08/2017 - 18:52 Pro Licensee


I'm marking this fixed, as it's actually been completed for a while now (it shipped in 5.99).

The loss of files when turning chroot off sounds bug-like. Can you open a new ticket about that? (I'm guessing it's due to the way homes get mounted into a chroot, which would then be unmounted when the chroot is turned off...but, we should handle that more gracefully. I doubt the data is actually gone, BTW. Does it come back when you turn chroot back on?)

And, we definitely need docs about it. I'll add that to my todo list.

I did more tests and nothing is lost. Actually all data will remain in /home/VM_user/. It is just a mount/umount between chroot and physical user folder. Turning chroot back on folder tree appears again. A white ball I like you didn't miss /etc/fstab for mouting at boot.

It seems we have a functional jailing in Virtualmin. People should be encouraged using it for reporting any bugs or lack of functionality. Docs should be provided in the next period. Thank you for your efforts.

This all sounds great..... but...

We installed installed "webmin-jailkit" and updated webmin* but nothing changed in the Virtualmin area.
We did see a "Jailkit Jail Manager" under "System" in "Webmin" but when we went to it we found we needed to install "libconfig-inifiles-perl".
We installed "libconfig-inifiles-perl" and are now getting:
"Error - Perl execution failed
Can't call method "Sections" on an undefined value at /usr/share/webmin/jailkit/index.cgi line 12."

Guessing some kind of initial setup when "webmin-jailkit" was added was not completed.
For example we have not located any configuration files for jailkit anywhere.


Joe's picture
Submitted by Joe on Wed, 10/11/2017 - 08:16 Pro Licensee

That's a wholly different issue rsecor. You don't have jailkit installed (webmin-jailkit is a Webmin module to provide a UI for editing jails it is not jailkit, just as the Webmin Apache module is not Apache, and the ProFTPd module is not ProFTPd, etc.).

jailkit is available in all of the new Virtualmin 6 repositories, and in some of the old repositories. It requires a custom build for our purposes, so random jailkit package probably won't work, it'll have to come from us. We add a php default jail config as well as build it with capabilities rather than suid binaries (which makes it safer).

If you want to talk more about getting it working on an older installation of Virtualmin (it is included by default in systems installed with the 6.0.x version of, it requires manual intervention for older installations), please post a new topic in the forum.

@Joe: For Debian/Ubuntu systems can I get the wbm-jailkit installation package? For the moment only RPM version is available.

Joe's picture
Submitted by Joe on Wed, 10/11/2017 - 09:23 Pro Licensee

That module requires the Config-INIfiles Perl module, as well. I think I've provided packages for CentOS, but I think it is available in the OS standard repos for Debian/Ubuntu.

There will soon be docs for migrating an existing old install to the new repos, as well as enabling new dependencies and features. Now that the issues with the new installation are mostly worked out, I can start working on that.

Closed (fixed)

@andreychek: I tried before using webmin-jailkit with no luck. Probably that package should be added to Debian Jessie branch too. I have to check the repository Virtualmin was setting up at the installation in my Debian 8 test machine . For sure it is not pointing to your Ubuntu path or the Debian VM universal. I can install it manually if something is going wrong. I appreciate for guiding me to the package location.\

UPDATE: I installed it a few moments ago with apt install. Someone added this package today for Debian/Ubuntu users :)

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.

Closed (fixed)
Needs review

Hello, I found this thread and I am really hoping that the original developer and implementer of the chroot jails for this can help. I have another topic with an issue that the chroot jails seem to be causing. I have a sandbox server setup to offer access if this can help resolve this issue.

The server install is a Ubuntu 16.04.5 (GNU/Linux 4.4.0-131-generic x86_64) complete up to date as of this thread

I really need to use the jails for security, so this problem for the issue I am going to post to another thread below I would greatly appreciate any help you can give. Please let me know how to get my server information to someone securely and I will provide that information as well.

the original support issue I created is below

We are even prepared to pay for this somehow. I did purchase a pro license in hopes that someone would help, but so much time went by and I got no replies on it we felt that we had to ask for a refund, but I will most definitely go back there right NOW and become a 250 / or unlimited yearly supporter. Please Please.

I have already looked at the fstab and the passwd file and they look fine to an armature like myself. I compared them with a server that has working "e-mail users and database users" restored from a backup in jailed mode, I have NOT tried to add or edit any of the users since that is where my problems arise. Please let me know if any of my details are unclear in the other thread and I will try to clarify them with as much detail as I can manage. Another alternative is to allow remote access to my desktop so I can show someone what is happening. Thank you, Thank you in advance.

To answer your question, I looked over the other thread, and yes it seems similar. If you take a look at my post above yours, I have a link to another thread where this issue is supposed to have been completely fixed, which I have been able to verify on a clean install.

I am a whole lot more detailed in this issue on this thread

Read through that and see if that sounds like your issue.

Good luck


I checked the /etc/passwd file of my chroots but these were correct so my search continue's.