jail -r & jail -R

[James Gritton]

On 2/14/2014 8:51 AM, dweimer wrote:
>
> I think I may have discovered a bug in the jail management system, if 
> you look at the man page for jail.
>
>  -r      Remove the jail specified by jid or name.  All jailed processes
>              are killed, and all children of this jail are also removed.
>
>  -R      A variation of the -r option that removes an existing jail with-
>              out using the configuration file.  No removal-related 
> parameters
>              for this jail will be used - the jail will simply be 
> removed.
>
> However I have discovered, even though -r says it can take either the 
> jail name or jail id, if you use the id it appears to function as if 
> you used the -R option instead, whereas using the -r option with the 
> name correctly stops the jail with the configuration parameters from 
> the jail.conf.
>
> I discovered this trying to figure out why the jails devfs system was 
> not dismounting, and my exec.poststop script was not running. I 
> discovered that if I used the name instead of id, I didn't run into 
> this issue.
>
> Can anyone else verify that this is a bug or invalid information in 
> man if its not, or do I have something wrong in my configuration, 
> below is a sample configuration and steps that can be used to 
> reproduce the issue.
>
> Example /etc/jail.conf:
>
> apache {
>         jid = 1;
>         host.hostname = apache.mydomainname.com;
>         ip4.addr = 192.168.1.2;
>         interface = em0;
>         path = /jails/apache/10.0-r260787-2014.02.12;
>         allow.mount.devfs;
>         mount.devfs;
>         allow.sysvipc;
>         exec.start = "/bin/sh /etc/rc";
>         exec.stop = "/bin/sh /etc/rc.shutdown";
>         exec.prestart = "/jails/apache/prestart.sh";
>         exec.poststop = "/jails/apache/poststop.sh";
>         exec.consolelog = "/jails/apache/console.log";
> }
>
> repeatable test scenario:
>
> jail -c apache
>   all looks good
> jail -r apache
>   all is right, jail devfs is gone, /jails/apache/proststop.sh ran.
> jail -c apache
>   all looks good
> jail -r 1
>   something is wrong
>     /jails/apache/10.0-r260787-2014.02.12/dev is still mounted
>     /jails/apache/proststop.sh hasn't run
>     jail is gone
>   do manually cleanup
>     umount /jails/apache/10.0-r260787-2014.02.12/dev
>     execute /jails/apache/proststop.sh script
> jail -c apache
>   all looks good
> jail -R apache
>   As expected
>     /jails/apache/10.0-r260787-2014.02.12/dev is still mounted
>     /jails/apache/proststop.sh hasn't run
>     jail is gone.

It's not exactly a bug, more what I'd call the limits of the program.
The "-r" option fills two functions, due to backward compatibility,
where the previous jail(8) used to be entirely unaware of the
configuration (knowing only the current kernel state).  So first it
will try to be an analog to "-c" and properly remove a jail that's
specified in the config file.  If it can't find that, it falls back to
the old behavior, which is the same as "-R": it just removes the jail
it finds in the kernel.

The limitation comes from how it attempts to find the jail in the
config file.  It just looks for a jail definition named after what's
specified on the command line.  In your care, there's a jail
definition for "apache" but not for "1".  It's true that the "apache"
jail has jid=1 specified; but that's only part of its definition, not
its identity.

This is different from "-R" looking in the kernel, where both jail
names and IDs are searched for.  So both "jail -R 1" and "jail -R
apache" find it in the kernel, where only "jail -r apache" finds it in
the config file.

- Jamie