From nobody Tue Oct 4 11:46:51 2022 X-Original-To: net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MhbXH5dxFz4dgXG for ; Tue, 4 Oct 2022 11:46:55 +0000 (UTC) (envelope-from avg@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) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4MhbXH43Klz3Th5; Tue, 4 Oct 2022 11:46:55 +0000 (UTC) (envelope-from avg@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1664884015; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Vdz4EFRl8s+vENA2en4oV9hy23byEBcgtvV5yWCu1u0=; b=AVaujcSeBQiRJgwEMOjETAm7p1gzvXpzJTPJkV+s4TbCXyTS7oBbzdJREvEsK0VYRjdHXw ZXuwZYHSMYUavyb4K9qGbRDnXlfa6Lyf0W7MiCep2kVIl88eCRUO/mOLvyOWZP+tgSQ33x YwrHcvKj+Bl0dKOsC56r00RzPpCc1P36IlCmCWY1boP0s6A+SnjEzYT3LGC/dl4pFf5DCB YuvQyka0fj8NE65hujFMApdm7nnDb0LCQDxbBaRgOjj2E1hJrwwVi8g26EVFw8UllhC9Rf Gv/Pr/9IAJpKMRJp2ltQWe2Uher4jUsygXMi6eVfHQ04knAJMS2w3RyFAPoQ8w== Received: from [192.168.0.88] (unknown [195.64.148.76]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: avg/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4MhbXH0S1Qz1MC6; Tue, 4 Oct 2022 11:46:54 +0000 (UTC) (envelope-from avg@FreeBSD.org) Message-ID: <9037ac3d-8d8e-2d7d-cbdb-996a53613aca@FreeBSD.org> Date: Tue, 4 Oct 2022 14:46:51 +0300 List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101 Firefox/102.0 Thunderbird/102.3.1 From: Andriy Gapon Subject: Re: in_pcbbind_setup: wrong condition regarding INP_REUSEPORT ? Content-Language: en-US To: Sean Bruno , "net@FreeBSD.org" References: <896ee089-27ad-c98f-6bf9-4b05caf778fd@freebsd.org> In-Reply-To: <896ee089-27ad-c98f-6bf9-4b05caf778fd@freebsd.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1664884015; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Vdz4EFRl8s+vENA2en4oV9hy23byEBcgtvV5yWCu1u0=; b=X9kCu2UVuGp+rFHw5GFkCHu6Ins8tkIdqbx5OjiKaeJVuaWcUN7hlPG7gZiRbyvpYunrow JBEM8D6ZPLpqtT07Nt/v+1xCVpQedmedKF7jzg7u/LqRHiiQeZF3jJf3xpqHPriah2xPoq ypGNJ3pG6aXqH9Y+pSN72z+HJ5mG91RvxhyUUiZ408koYLzOvdQe3V4m9skk11OHdoKgLe /Rf0z7TRt8L4SRsTSWCpZ6SwcQH2hylclcp4PrqsrU/CylrPN+IsqmWoWlO02ays5nlDVv 7VFkMRSa54+rxg/GiKtA+WWuncBFaMMtHbm3eBcohPWwWttNoHaUqCMgCdScBA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1664884015; a=rsa-sha256; cv=none; b=lOWSOVf0F64s0j2jgP134OsOPgv86/VdmDCU6QlJv+6mTFKkgt7PNzZlopGc1B0g4sAOuo JVtj5fsVJMYM1q/9U8ExWgtxxCEaHtkxj9gOH8rX/eoVwokhydbiwSEgyc+qomnnAvFgkY 6072EiJvHpjwclFTRSLugW70plhcj/+iPYDMsjwJdlzV0DiRmD5YcJOmgpw4AuELN0RlVH 6OJWNpfLMpEKnhZdpczRU4Kby4Q0G055rgg8mRymmZjVtjhiLxLtI/h1ZOjbdUyFilkyY7 BvEKt0KyPHtGToVQ3VedDzM99D19go13K7hsSiQDbpaeoFgM1/EPTXaaBa5kbg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N On 04/10/2022 14:37, Sean Bruno wrote: > > > On 10/3/22 04:14, Andriy Gapon wrote: >> >> I must admit that the condition in question is fairly long and non-trivial and >> I cannot decipher it, but these two lines look wrong to me: >> >>                                       (t->inp_flags2 & INP_REUSEPORT) || >>                                       (t->inp_flags2 & INP_REUSEPORT_LB) == 0) && >> >> I'd expect that the check would be symmetric with respect to INP_REUSEPORT and >> INP_REUSEPORT_LB. >> The problem seems to come from 1a43cff92a20d / r334719 / D11003. >> > > I think you are pointing at this absurd conditional? > > https://cgit.freebsd.org/src/tree/sys/netinet/in_pcb.c#n1049 > > Besides the twisted logic, what problem are you trying to solve? Yes, that conditional. I pointed out the part of it that does not make sense to me. Also, in my tests SO_REUSEPORT does not actually allow to share a port. Test scenario: - create a UDP socket - setsockopt(SO_REUSEPORT) - bind the socket to a port and wild card address - success - now repeat the previous steps with the same port *under a different user id* - bind fails I wonder if the following would be a correct change. diff --git a/sys/netinet/in_pcb.c b/sys/netinet/in_pcb.c index d9247f50d32b..f5e6e3932a96 100644 --- a/sys/netinet/in_pcb.c +++ b/sys/netinet/in_pcb.c @@ -1003,6 +1003,7 @@ in_pcbbind_setup(struct inpcb *inp, struct sockaddr *nam, in_addr_t *laddrp, /* * XXX * This entire block sorely needs a rewrite. + * And a good comment describing the rationale behind the conditions. */ if (t && ((inp->inp_flags2 & INP_BINDMULTI) == 0) && @@ -1011,8 +1012,7 @@ in_pcbbind_setup(struct inpcb *inp, struct sockaddr *nam, in_addr_t *laddrp, ntohl(t->inp_faddr.s_addr) == INADDR_ANY) && (ntohl(sin->sin_addr.s_addr) != INADDR_ANY || ntohl(t->inp_laddr.s_addr) != INADDR_ANY || - (t->inp_flags2 & INP_REUSEPORT) || - (t->inp_flags2 & INP_REUSEPORT_LB) == 0) && + (t->inp_flags2 & (INP_REUSEPORT | INP_REUSEPORT_LB)) == 0) && (inp->inp_cred->cr_uid != t->inp_cred->cr_uid)) return (EADDRINUSE); -- Andriy Gapon