Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 25 Jan 2025 20:44:25 +0000
From:      Paul Vixie <paul@redbarn.org>
To:        Mark Johnston <markj@freebsd.org>
Cc:        "freebsd-net@freebsd.org" <freebsd-net@freebsd.org>
Subject:   Re: per-FIB socket binding
Message-ID:  <2223592.Mh6RI2rZIc@localhost>
In-Reply-To: <Z4ViiO1LsAIvD2Mu@nuc>
References:  <7772475.EvYhyI6sBW@dhcp-151.access.rits.tisf.net> <2841433.BEx9A2HvPv@localhost> <Z4ViiO1LsAIvD2Mu@nuc>

next in thread | previous in thread | raw e-mail | index | archive | help
On Monday, January 13, 2025 6:59:20 PM UTC Mark Johnston wrote:
> On Sun, Jan 12, 2025 at 07:17:48AM +0000, Paul Vixie wrote:
> > On Saturday, January 11, 2025 4:51:07 PM UTC Mark Johnston wrote:
> > > On Sat, Jan 11, 2025 at 06:25:22AM +0000, Paul Vixie wrote:
> > 
> > this is exactly my understanding of that code. the FIB for the SYN|ACK
> > will be the one from the interface who received the SYN.
> 
> What I'm saying is that today, the FIB for the SYN|ACK will be that of
> the listening socket, not that of the receiving interface.
> sc->sc_inc.inc_fibnum comes from the listening socket, not the SYN.

thanks for beating me over the head with the facts of the case. i'd simply 
forgotten that my earliest patch preferred the SYN's FIB number over the 
listener socket's FIB number if only the former was nonzero.

> > ...
> > i've begun to wish for a setfib_fd(2) which would let sshd promote the FIB
> > from an inbound connection to be process-wide (after fork() before
> > exec().)
> > that way "netstat -rn" would show the routing table actually being used by
> > the stdin and stdout of that shell. or perhaps we could just rename
> > SO_SETFIB to be SO_FIB and allow getsockopt() to return the FIB? (i'm not
> > sure why it was "set only" in the current implementation.) opinions
> > welcomed, as before.
> ...
> I think the second option is fine, given that we have setfib(2) already:
> ...

i think i would do it a little differently, making SO_FIB both gettable and 
settable, and leaving SO_SETFIB as an alias for SO_FIB that is set-only, and 
documenting SO_SETFIB as an alias for backward compatibility. and if we're 
going to do this for sockets, we need a getfib() syscall to do it for 
processes.

however, before doing this, i'd want to know why there was never an SO_GETFIB 
since its absence may be deliberate (for some security related purpose.) in 
such case my setfib_fd() proposal would propagate a socket's FIB to be 
process-wide without revealing the FIB itself to the calling process.

does anyone remember why the FIB of a socket or process cannot be discovered 
from user mode? lack of motivation -- or deliberate design decision?

-- 
Paul Vixie





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