Tech Blog (wh)

Recently I began testing `jailkit` on Ubuntu 12 and 12.04 and wanted users to have access to `cron` and `crontab`

I read a lot of the documentation for `man cron` and have a pretty good understanding of how Vixie Cron works.

There is a bit of a conflict with permissions of Cron and Jailkit.

Jailkit wants most everything inside the jail (most often `/home/jail/`) to be owned by `root` and in the `root` group, and basically nothing to be writable by the jailed users (except for `/home/jail/tmp/` and the users home directories in `/home/jail/home/*`)

Cron, on the other hand, doesn’t want you to edit the crontab files for the users directly. They live in `/var/spool/cron/crontabs`

> cron searches its spool area (/var/spool/cron/crontabs) for crontab files (which are named after accounts in /etc/passwd); crontabs found are loaded into memory. Note that crontabs in this directory should not be accessed directly – the crontab command should be used to access and update them.

More information is given from `man crontab`:

> There is one file for each user’s crontab under the /var/spool/cron/crontabs directory. Users are not allowed to edit the files under that directory directly to ensure that only users allowed by the system to run periodic tasks can add them, and only syntactically correct crontabs will be written there. This is enforced by having the directory writable only by the crontab group and configuring crontab command with the setgid bid set for that specific group.

That’s great, but…

##How do I set up crontab with Jailkit on Ubuntu?

Disclaimer: This may not be 100% correct but it worked for me.

First, hardlink the crontab directory into your jail:

jk_cp -vkof /home/jail /var/spool/cron/crontabs

-v – verbose
-k – hardlink
-o – owner – Retains the file ownership and group when copying files and directories.
-f – force – Force overwriting of existing files

This will only do the directory so you may need to hardlink the individual files inside of the crontabs folder afterwards using `ln` without the normal symlink method of `ln -s`… and remember, **hardlinks are generally very bad so don’t get into the habit of using them.** However, after a user has been `chrooted` symlinks will appear broken so they are not an option here.

The ownership and permissions on this folder, inside the jail, need to match the permissions of the real files. That is, the folder should be owned by `root` and have the group `crontab` with permissions listed as `drwx-wx–T`

Inside the crontab folder, each user who needs to edit a crontab needs their file hardlinked into the jailed `/var/spool/cron/crontabs` folder and the hardlinks need to be owned by the user and of have the group `crontab` and the permissions need to be set as `-rw——-`

**Update** – hard links won’t work because when using `crontab` to edit the files, well, it doesn’t actually edit them. It deletes them and replaces them. Here’s the solution I’ve found instead:

Use the command mentioned earlier to copy the `crontabs` directory:

jk_cp -vkof /home/jail /var/spool/cron/crontabs

Now remove that last directory:

sudo rm -R /home/jail/var/spool/cron/crontabs

The parent directories will still exist. Now recreate that directory:

sudo mkdir /home/jail/var/spool/cron/crontabs

Next you will need to edit `/etc/fstab` and create a binding. If you aren’t *very careful* editing this file may brick your system – not immediately but it may keep it from booting up. First create a copy of the file:

sudo cp /etc/fstab ~/fstab

Now you can edit the file with something like:

vi /etc/fstab

What you’ll do is create a binding so that the real crontab directory is available in two places. You had to create the other directory as a mount point (and remove the files / folder first). So on the last line of /etc/fstab add something like:

/var/spool/cron/crontabs /home/jail/var/spool/cron/crontabs none bind

If you mess anything up in this file and your system won’t boot, you will need to get your system into recovery mode where you can make changes to the `/etc/fstab` file (attach the drive to a working system) and fix it.

Once that is done you can run:

mount /home/jail/var/spool/cron/crontabs

Now `/home/jail/var/spool/cron/crontabs` is bound to `/var/spool/cron/crontabs` – it is sort of like a symlink at the system level. Check out `man bind` and `man fstab` for more info.

You will also need to use jk_cp to copy in the `/usr/bin/crontab` binary file so your users can edit the crontabs. However, the permissions and ownership on the file are very important.

jk_cp -vof /home/jail /usr/bin/crontab

Again, they should match the permissions and ownership of the real file, and you WILL need to manually set this after using jk_cp to copy the file to the jail.

If you jail home is `/home/jail` you can do something like:

chmod g+s /home/jail/usr/bin/crontab

The `/usr/bin/crontab` file should be owned by `root` and of the group `crontab` with the `setgid` bit set (g+s) so that when it is executed it runs as the group’s owner (i.e. crontab) – so the permissions should look like `-rwxr-sr-x` – check this by running:

ls -l /home/jail/usr/bin/crontab

The only other tricky bit is that if you create a new user on your system you will need to create a crontab file for them – perhaps using something like `su crontab -e -u mynewuser` and then save / exit your editor.

You will now need to manually create a hardlink from the jail’s crontab file to the real one:

`/var/spool/cron/crontabs/mynewuser` will be hardlinked as `/home/jail/var/spool/cron/crontabs/mynewuser`

As root you can do something like:

cd /home/jail/var/spool/cron/crontabs/
ln /var/spool/cron/crontabs/mynewuser

Again, check the permissions match as mentioned above. Good luck.