Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 13 Dec 2022 11:43:22 -0800
From:      James Gritton <jamie@freebsd.org>
To:        jail@freebsd.org
Cc:        "glebius@FreeBSD.org" <glebius@freebsd.org>, Andrew Gallatin <gallatin@gmail.com>, "Bjoern A. Zeeb" <bz@freebsd.org>
Subject:   Re: prison_flag() check in hot path of in_pcblookup()
Message-ID:  <2a96726f498df08c57bf54eff2afc960@freebsd.org>
In-Reply-To: <89pn26q0-pps9-q8n7-1334-q15o5896p6p@serrofq.bet>
References:  <CADwhF6VuoPCNEqyBmt%2BdZgDwHdaGty2%2BsYU4eYg0_62CMHq-BA@mail.gmail.com> <e5ef5a4dfae8f7723c10dfb8db9b7d9a@freebsd.org> <89pn26q0-pps9-q8n7-1334-q15o5896p6p@serrofq.bet>

next in thread | previous in thread | raw e-mail | index | archive | help

On 2022-12-13 11:03, Bjoern A. Zeeb wrote:
>>> In either case, a perfect 4-tuple match should be enough to uniquely 
>>> identify the connection.
>>> 
>>> Even if this somehow is not the case and we have multiple connections 
>>> somehow sharing the same 4-tuple, how does checking the prison flag 
>>> help us?
> 
> That logic predates me and came from [1].  The 
> jail_jailed_sockets_first
> sysctl got removed in the review process with rwatson.  I am still 
> trying
> to see where the SO_REUSEPORT comment (back then) came from.  I know I
> only had the first lines initially, so must have been sometime during
> review with rwatson as well.   Sadly p4 emails where truncated to 1000
> lines so I cannot simply grep for the change (if it is in my mail
> archives) or had a useful commit message (but at least would give a
> date to check further private email).
> 
> My current guess is that if we have the 4-tuple in both the base
> and a jail (hence the SO_REUSEPORT comment) we want the jail not 
> getting
> a socket of the base system returned as that would mean one could 
> "break
> out of prison".  But if the inp belongs to a jail we know we can simply
> return.  So if you find the one of the base system first you'll have to
> go and look through the others.
> 
> XXX-jamie: is that all still true in hierarchical jails?

I believe so...

Multiple jails in a hierarchy can share the same single IP address,
but then you also could always have multiple non-hierarchical jails
sharing the same single IP address.  So in the single-address case,
hierarchy doesn't matter.

prison_ip_conflict_check() notably doesn't distinguish parent jails
from the broader class of "other jails," which means that only the
first-level jails in a hierarchy can have multiple IP addresses.  So
the multi-address case doesn't apply to hierarchical jails.

- Jamie



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2a96726f498df08c57bf54eff2afc960>