On Thu, Aug 1, 2019 at 1:38 AM Ari Suutari via freebsd-stable
<freebsd-stable at freebsd.org> wrote:>
> Hi,
>
> We have a lot of servers using jails and ipfw rules with
> numeric jail ids to limit acess between them (something
> like 'allow tcp from from me to me 8086 jail 1 keep-state').
>
> This has been working very well for ages. Yesterday, we upgraded
> first of these servers to 11.3. During boot there are now messages
> like 'ipfw: jail 1 not found' and the rules are not loaded.
>
> I tracked this down to:
> https://reviews.freebsd.org/rS348304
>
> ipfw calls jail_getid, which used to just return the id without checking
> if string was numeric. In 11.3, the function has been changed to actually
> check if the jail with given id exists.
>
> This doesn't really work in ipfw's context as the rules are loaded
before
> the jails are actually created.
>
> Ari S.
Hi,
I've CC'd Andrey, who tends to work in this area. Apologies for not
catching the breakage- I'll whip up a patch unless Andrey objects, but
this area feels a bit finnicky. I think a couple of things need to
happen:
1.) To fix things -right now-, ipfw should fall back to strtoul if
jail_getid fails and only error out if strtoul fails. This restores
the functional status quo and still uses jail_getid properly, which is
documented to return -1 if the jail does not exist.
2.) One of these:
- a.) ipfw(8) needs revision, or
- b.) the kernel interface needs to change a bit
#2 options are mutually exclusive, I think- the problem is that jail
jid/name rules will be usable at different times, and it's not
immediately clear when that is to someone (me) who has never used ipfw
before.
jid historically works at all times and operates on any jail that ends
up having that jid.
name can only be functional if the jail's already running when the
rule is processed by ipfw(8) and applies to whatever jid has that name
at that time. If the jail gets restarted with a different jid, it
won't apply to the jid that that name has after the restart unless the
rule is reprocessed.
Thanks,
Kyle Evans