From owner-svn-src-head@freebsd.org Mon Apr 10 14:43:19 2017 Return-Path: Delivered-To: svn-src-head@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 E30DAD376A9 for ; Mon, 10 Apr 2017 14:43:19 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::236]) (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 A2B12ED7 for ; Mon, 10 Apr 2017 14:43:19 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: by mail-oi0-x236.google.com with SMTP id b187so150425173oif.0 for ; Mon, 10 Apr 2017 07:43:19 -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=qGuV2kUJsnUgrBvHroKGn+Dvhc5/xf/eQeKWNCJEVJaJIdxGRizPdC1nYyDE/2OR1o KAyIAwygbSioGd1NqID0h+ik4JlHpxkwfXCT7jsbHFQ/YKX58gez6QXXXXWmIYosswhN H9rKHdzthJn6PFqWeczsGVkAZa9g13sW7kSqTu7egDKVrdggWu/A1tI1MAZ6PQUlt9/B TVfKXspLZGMZEEAOY5WrZFLx6dDt5vWKXob2dbS/Qwp/05AiXB/s2/cBE4ExMY75tZir omlKgV/EbZhZM3Se7qFufkz+7ylw0Z8mtPIpMTyu9zhHp4ZbeSxnvWM8lIqBIFb4s7eP kUkw== X-Gm-Message-State: AN3rC/5PcEEVznhiVGDKkcfiVJtGRUDCzaP4vaejNn4HNLIP7Ami468m8h0xmy0ePt3XwKMkOjNdxr9s01njyLx/ 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-head@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2017 14:43:20 -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 > >