lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Sat, 16 Jul 2016 15:38:40 +0530
From:	Pranay Srivastava <pranjas@...il.com>
To:	Alex Bligh <alex@...x.org.uk>
Cc:	Markus Pargmann <mpa@...gutronix.de>,
	"nbd-general@...ts.sourceforge.net" 
	<nbd-general@...ts.sourceforge.net>, Wouter Verhelst <w@...r.be>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [Nbd] [PATCH 2/2] nbd: Disallow ioctls on disconnected block device

On Sat, Jul 16, 2016 at 3:02 PM, Alex Bligh <alex@...x.org.uk> wrote:
>
> On 16 Jul 2016, at 08:42, Pranay Srivastava <pranjas@...il.com> wrote:
>
>> So instead can't we put a mechanism in place for network address + mac
>> to be same
>> for allowing clients to reconnect? Do let me know if this is not of concern.
>
> MAC address?! nbd clients connect over IP, and if a router reboots
> between them, you could easily see two packets from the same client
> come from different MAC addresses. Similarly all clients not on
> the same L2 network will carry the same MAC address. So MAC address
> is a very poor indicator of 'same client'.
>
> IP address is also a poor indicator (think NAT) but is substantially
> less bad.

Okay. So how about we include some negotiated key which goes in with every
request which the server could maintain for clients that can be checked while
resetting the connection with the same server?

So am I correct that this situation can
indeed happen or the server will throw an error back to client in case
the troubled
nbd-client is trying to reconnect to the original server but requests
are going to
another server?

If yes to above query then what is the best effort we can do to avoid
such scenarios?

>
> --
> Alex Bligh
>
>
>
>



-- 
        ---P.K.S

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ