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