From owner-svn-src-all@freebsd.org Mon Apr 10 14:43:21 2017 Return-Path: Delivered-To: svn-src-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3E91AD376B3 for ; Mon, 10 Apr 2017 14:43:21 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0314BEDB for ; Mon, 10 Apr 2017 14:43:21 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: by mail-io0-x22a.google.com with SMTP id r16so43473395ioi.2 for ; Mon, 10 Apr 2017 07:43:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sippysoft-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:from:date:message-id:subject:to:cc; bh=n0TSvGB58HLpA+Df/BNlBbeuE0Bc1MwzXZJGKpJjxVI=; b=kyLgazzqVn3q1AaQturl7hNwV1rnSGuud6BDDRxS5US+lRJMUhn2947ZHIDGrOigEF o6C6RTZ9rt7LmKlko5jmqfQEaO65ne3AuOkkSbQDejmWB1ENY0dLtvWh3krDjJnNnkH8 oc9WwvwWmNydjCXkowIxNPNAO6TBxR1UCav+KLcDcjDGrfqok/7LbGaC+ABsxeTfn6D9 36sROrmJ0XDP20iiSrZgL/94l8rORpSeQlXa56S3df4WmkRVmyKSiOfikEu6LIlASdXr OuLf3SOKM8Bg2hX9a/IgFnZP4WUr8bxVoXoMCqm5UR1vp2s8YBfWiCab3yY7+VeS89o8 Usiw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to:cc; bh=n0TSvGB58HLpA+Df/BNlBbeuE0Bc1MwzXZJGKpJjxVI=; b=Jf0AzvcRmcgzGoP/+Wjw6BLw/p8z2cXD/x16zgS+ikYBMGYu303dkzZWTedVkkemsO Aulhz4JFrZ2j+I/0OSpmQbHnGd07UmqhzL/OMrRM2Ehnm9BUIjCf0iUv3ajosrxoWXNd 1o6nfUgeFHPYKGxFEaDKEKBncUeZmMdxTlmP+6zjpl1AwLWlwR7+Pf2XQwi9DI95NBkQ zOd4WF3jEpFXImLxZYb3jxxrASimoTChib6JNS4P4AHlmvp8wbAK7F2YcNujqdk2f3sl aS0YnH84wct2e31QRN+Y454/73byxyGT2Rbf0jd6Uutf8aZX81IgoNBzfus8vZfrythW XZdg== X-Gm-Message-State: AN3rC/462xRVdSN6NVUfhbXcdcW53b37XubBBBTgfMjRmihMh0u/OzDKKN2Puh4sjgjPv7HlktyEIVcL5Yr+b286 X-Received: by 10.36.47.78 with SMTP id j75mr12342902itj.72.1491835398795; Mon, 10 Apr 2017 07:43:18 -0700 (PDT) MIME-Version: 1.0 Sender: sobomax@sippysoft.com Received: by 10.36.112.210 with HTTP; Mon, 10 Apr 2017 07:43:18 -0700 (PDT) From: Maxim Sobolev Date: Mon, 10 Apr 2017 07:43:18 -0700 X-Google-Sender-Auth: g-9ZBlkpvRCQMJ6HOriztZACAMM Message-ID: Subject: On shutting down UDP socket [Re: svn commit: r285910 - in head: lib/libc/sys sys/kern sys/sys] To: Ed Schouten Cc: Alexander Kabaev , Ed Schouten , src-committers , svn-src-all@freebsd.org, svn-src-head@freebsd.org, mjg@freebsd.org, gnn@freebsd.org, network@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2017 14:43:21 -0000 Hi Guys, I am sorry to bring this old thread up, but I think Ed's comparison with other OSes here and in the relevant differential was not entirely correct. What linux does (tested with 4.4.0) when UDP socket is shut down is actually shutting down receiving end, so any threads that are blocked in recv() on that socket return. Still shutdown() system call itself returns ENOTCONN. FreeBSD on the other hand does not do anything for the socket, so that the threads just hang. I am pretty sure there are at least some software out there that relies on that behavior, at least in our case we do. Bumped into this after upgrading to the 11.0. Therefore, I am curious about possibility to make our behavior match that of Linux's, so we are not the odd one with regards to this, that is return an error but still shutdown the socket? Small test case is attached. Both FreeBSD 10.3 and Linux 4.4.0 pass (albeit Linux's shutdown() returns with an error), FreeBSD 11.0 fails. -Max On Sun, Aug 9, 2015 at 6:08 AM, Ed Schouten wrote: > Hi Alexander, > > 2015-08-09 14:55 GMT+02:00 Alexander Kabaev : > > On Sun, 9 Aug 2015 09:37:13 +0200 > > It most definitely does work, this is what I have done to get my > > network scripts work again. I wonder if there are other means of > > restricting raw sockets that can be used to achieve the result > > authors of rtsold had hoped or? > > Yes, there sure are. We could for example call cap_rights_limit() on > the socket and whitelist the exacty set of actions that the program > needs. > > That said, it wouldn't make a difference in the end. It looks like > rtsol/rtsold don't seem to drop any privileges or switch credentials > after startup, assuming I haven't overlooked anything. Even if we were > to restrict the raw socket, the process could always open a new one > later on. > > I think it would make sense for now to just commit the patch that I > proposed. Will push it into the tree tomorrow. > > Thanks, > -- > Ed Schouten > Nuxi, 's-Hertogenbosch, the Netherlands > KvK/VAT number: 62051717 > >