From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mailout4.w1.samsung.com (mailout4.w1.samsung.com [210.118.77.14]) by dpdk.org (Postfix) with ESMTP id 3CD4911A2 for ; Tue, 15 Dec 2015 15:21:27 +0100 (CET) Received: from eucpsbgm2.samsung.com (unknown [203.254.199.245]) by mailout4.w1.samsung.com (Oracle Communications Messaging Server 7.0.5.31.0 64bit (built May 5 2014)) with ESMTP id <0NZE00DFIL7PMO00@mailout4.w1.samsung.com> for dev@dpdk.org; Tue, 15 Dec 2015 14:21:25 +0000 (GMT) X-AuditID: cbfec7f5-f79b16d000005389-ad-567021e5256c Received: from eusync4.samsung.com ( [203.254.199.214]) by eucpsbgm2.samsung.com (EUCPMTA) with SMTP id 81.67.21385.5E120765; Tue, 15 Dec 2015 14:21:25 +0000 (GMT) Received: from fedinw7x64 ([106.109.131.169]) by eusync4.samsung.com (Oracle Communications Messaging Server 7.0.5.31.0 64bit (built May 5 2014)) with ESMTPA id <0NZE00BOXL7OCY90@eusync4.samsung.com>; Tue, 15 Dec 2015 14:21:25 +0000 (GMT) From: Pavel Fedin To: 'Yuanhan Liu' References: <00c101d13735$e85453d0$b8fcfb70$@samsung.com> <20151215140450.GL29571@yliu-dev.sh.intel.com> In-reply-to: <20151215140450.GL29571@yliu-dev.sh.intel.com> Date: Tue, 15 Dec 2015 17:21:25 +0300 Message-id: <00cd01d13743$e1a7c4a0$a4f74de0$@samsung.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-index: AQFypYAHB38J6yzPdnR5UP981PiydwHLO7+Pn3rhwOA= Content-language: ru X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrGLMWRmVeSWpSXmKPExsVy+t/xa7pPFQvCDJr/alu8+7SdyeJK+092 i8mzpSyuT7jA6sDi8WvBUlaPeScDPfq2rGIMYI7isklJzcksSy3St0vgyljz9zJTwUG2irNr FjM2ME5m7WLk5JAQMJHom93KAmGLSVy4t56ti5GLQ0hgKaNE86U3rBDOd0aJZ1ceMYJUsQmo S5z++gGsQ0RAX+LTVohuZoEUiWVHZoHZQgJZEkueXQezOQWsJXa2bmQCsYUFjCRaVt9lA7FZ BFQltrTNB5vJK2Ap8XHjRmYIW1Dix+R7UDO1JNbvPM4EYctLbF7zlhniUgWJHWdfM0LcYCXR 8nwzK0SNiMS0f/eYJzAKzUIyahaSUbOQjJqFpGUBI8sqRtHU0uSC4qT0XCO94sTc4tK8dL3k /NxNjJDQ/7qDcekxq0OMAhyMSjy8C5jzw4RYE8uKK3MPMUpwMCuJ8JqJFoQJ8aYkVlalFuXH F5XmpBYfYpTmYFES5525632IkEB6YklqdmpqQWoRTJaJg1OqgVFzVqzN9D+zxA99ULevf8hV f3ByXfLO/c2n27PizwX+tVqQLif9XS/t/5Pi5dLLmnY/3TunOs94Ynb9uTU7JFuWxCg9v71n 8pyjRVITp/pte+5z7P7uxay9LZFd89zjXAp9qub27rnbZ1OrMXXGlfn3wn4aCVTdXO0i3aOx 6vafQ7XLL3tskBFVYinOSDTUYi4qTgQAM2tfZHkCAAA= Cc: dev@dpdk.org, 'Ilya Maximets' , 'Dyasly Sergey' Subject: Re: [dpdk-dev] problem vhost-user sockets X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2015 14:21:27 -0000 Hello! > I'm thinking you can't simply unlink a file given by a user inside > a libraray unconditionaly. Say, what if a user gives a wrong socket > path? Well... We can improve the security by checking that: a) The file exists and it's a socket. b) Nobody is listening on it. > I normally write a short script to handle it automatically. I know, you can always hack up some kludges, just IMHO it's not production-grade solution. What if you are cloud administrator, and you have 1000 users, each of them using 100 vhost-user interfaces? List all of them in some script? Too huge job, i would say. And without it the thing just appears to be too fragile, requiring manual maintenance after a single stupid failure. Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia