Change Details

A design error of my original jail work was to allow jails that weren't fully removed to be be brought back from the almost-dead, as if they had never been removed. This was a way to allow the other design error of allowing jails to specified by jid, without having to wait (usually a few minutes, often much longer) for the old jail to release all resources. This has always been a messy solution, as it means that a "created" jail may or may not have remnants of its previous existence. The problem is users are now well-used to being able to specify jails by jid (even though it's not encouraged), and with "-d" or "allow.default" to re-create them without waiting. The solution is to continue to allow this at the user level, without ever re-using removed jails at the kernel level. It's already the case that a new jail can be created with the same name as one that's waiting to let go of resources. With this patch, it's also possible to created a jail with the same jid as an existing dying jail. This is done by silently renumbering the old dying jail to a new dynamic jid, thus freeing it up for the new jail to use. This obsoletes the ALLOW_DYING flag to jail_set(8), though it remains allowed as a no-op (and is still used by jail_get(8)). The upside is that newly created jails are always pristine, with only the parameters set that are given in their creation. The downside is that in this once specific instance, jail IDs are no longer immutable. This may confuse users that are specifically looking at dead jails by jid, and not expecting a new jid to show up in an old jail, but that's a small and presumably very uncommon price to pay. There have been rumblings of security problems associated with jail resurrection, and this stops any of these problems from occurring. The is the second of two related changes, the other being D27876. I though I'd split the work into roughly equal parts, but it turns out this is the much bigger chunk, with seemingly unrelated part of the jail code refactored to accommodate the main change.

A design error of my original jail work was to allow jails that weren't fully removed to be be brought back from the almost-dead, as if they had never been removed. This was a way to allow the other design error of allowing jails to specified by jid, without having to wait (usually a few minutes, often much longer) for the old jail to release all resources. This has always been a messy solution, as it means that a "created" jail may or may not have remnants of its previous existence. The problem is users are now well-used to being able to specify jails by jid (even though it's not encouraged), and with "-d" or "allow.default" to re-create them without waiting. The solution is to continue to allow this at the user level, without ever re-using removed jails at the kernel level. It's already the case that a new jail can be created with the same name as one that's waiting to let go of resources. With this patch, it's also possible to created a jail with the same jid as an existing dying jail. This is done by silently renumbering the old dying jail to a new dynamic jid, thus freeing it up for the new jail to use. This obsoletes the ALLOW_DYING flag to jail_set(8), though it remains allowed as a no-op (and is still used by jail_get(8)). The upside is that newly created jails are always pristine, with only the parameters set that are given in their creation. The downside is that in this once specific instance, jail IDs are no longer immutable. This may confuse users that are specifically looking at dead jails by jid, and not expecting a new jid to show up in an old jail, but that's a small and presumably very uncommon price to pay. There have been rumblings of security problems associated with jail resurrection, including some recent SAs. This is meant to stop more of these problems from occurring.

A design error of my original jail work was to allow jails that weren't fully removed to be be brought back from the almost-dead, as if they had never been removed. This was a way to allow the other design error of allowing jails to specified by jid, without having to wait (usually a few minutes, often much longer) for the old jail to release all resources. This has always been a messy solution, as it means that a "created" jail may or may not have remnants of its previous existence. The problem is users are now well-used to being able to specify jails by jid (even though it's not encouraged), and with "-d" or "allow.default" to re-create them without waiting. The solution is to continue to allow this at the user level, without ever re-using removed jails at the kernel level. It's already the case that a new jail can be created with the same name as one that's waiting to let go of resources. With this patch, it's also possible to created a jail with the same jid as an existing dying jail. This is done by silently renumbering the old dying jail to a new dynamic jid, thus freeing it up for the new jail to use. This obsoletes the ALLOW_DYING flag to jail_set(8), though it remains allowed as a no-op (and is still used by jail_get(8)). The upside is that newly created jails are always pristine, with only the parameters set that are given in their creation. The downside is that in this once specific instance, jail IDs are no longer immutable. This may confuse users that are specifically looking at dead jails by jid, and not expecting a new jid to show up in an old jail, but that's a small and presumably very uncommon price to pay. There have been rumblings of security problems associated with jail resurrection, and this stops any of these problems from occurring. The is the second of two related changes, the other being D27876including some recent SAs. I though I'd split the work into roughly equal parts, but it turns out this is the much bigger chunk, with seemingly unrelated part of the jail code refactored to accommodate the main changeThis is meant to stop more of these problems from occurring.