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
