From owner-freebsd-stable@freebsd.org Thu Aug 1 13:44:26 2019 Return-Path: Delivered-To: freebsd-stable@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id EFE1CBE38F for ; Thu, 1 Aug 2019 13:44:26 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 45zs3G67Tlz4fPM; Thu, 1 Aug 2019 13:44:26 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from mail-wr1-f53.google.com (mail-wr1-f53.google.com [209.85.221.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id 874B71307D; Thu, 1 Aug 2019 13:44:26 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-wr1-f53.google.com with SMTP id r1so73638003wrl.7; Thu, 01 Aug 2019 06:44:26 -0700 (PDT) X-Gm-Message-State: APjAAAVmwbKRbsuStHaApr3/te4Hld1lKa/jl7Tl80mE/BNPkTMW1U2o 0AvSKKfQ8FSdu/Qin3P+Ch/F/LXhbc/m4OTtshk= X-Google-Smtp-Source: APXvYqz8mp3vHVWoHNQe+/KK4xgyMM1XDNX5IQR3RYVuUnuO7BS6BJ2j/4JOc5Uhqc/J5i3haEUz4R4WzajtnpXHoqA= X-Received: by 2002:adf:ce8d:: with SMTP id r13mr48757095wrn.37.1564667065429; Thu, 01 Aug 2019 06:44:25 -0700 (PDT) MIME-Version: 1.0 References: <8ef12e33-583e-5b5c-a602-155e396a6a45@stonepile.fi> In-Reply-To: <8ef12e33-583e-5b5c-a602-155e396a6a45@stonepile.fi> From: Kyle Evans Date: Thu, 1 Aug 2019 08:43:42 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: ipfw jail keyword broken in 11.3 by jail_getid changes To: Ari Suutari Cc: FreeBSD-STABLE Mailing List , "Andrey V. Elsukov" Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 45zs3G67Tlz4fPM X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-0.02 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-0.00)[-0.002,0]; NEURAL_HAM_SHORT(-0.02)[-0.019,0]; ASN(0.00)[asn:11403, ipnet:2610:1c1:1::/48, country:US] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2019 13:44:27 -0000 On Thu, Aug 1, 2019 at 1:38 AM Ari Suutari via freebsd-stable 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